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Prefácio da 4 a Edição 


Depois de muitos anos estudando e analisando dezenas de autores e espe¬ 
cialistas que escrevem sobre as estratégias organizacionais, percebe-se que a 
Gestão Estratégica da Informação tornou-se um dos principais fatores críticos 
de sucesso das organizações. Dessa forma, o papel estratégico da informação 
precisa ser entendido como fonte de vantagem competitiva pelas empresas e 
isso requer saber lidar com a informação e utilizá-la de maneira pronta e ren¬ 
tável. Estar na frente dos concorrentes, criar novas soluções e produtos, inovar 
e ultrapassá-los depende de saber lidar com a informação. 

Desde a primeira edição deste livro, os autores Aguinaldo Aragon Fernan¬ 
des e Vladimir Ferraz de Abreu, especialistas consagrados da área, mostram 
o caminho que as empresas, de todos os tipos e tamanhos, precisam trilhar 
em busca da excelência e eficácia no uso da Tecnologia da Informação, desde 
os fatores motivadores para uma gestão da TI até o detalhamento dos prin¬ 
cipais modelos disponibilizados no mercado nacional e internacional. Eles 
dedicam um capítulo completo à discussão do alinhamento estratégico da 
TI, na busca de agregar valor ao negócio da organização, dando uma visão 
completa e abrangente do papel da Governança de TI dentro das estratégias 
empresariais. 

Especificamente nesta quarta edição, diversos modelos e suas práticas fo¬ 
ram revisados, destacando-se o modelo Cobit que foi totalmente reescrito 
dentro da nova visão do lançamento da edição do Cobit 5 no ano de 2012, 
que integrou os conteúdos do Cobit 4.1, Val it, RISK IT, BMIS, ITAF e 
TGE Modelos tais como o ITIL, PMBOK e MR.MPS também foram com¬ 
plementados nesta edição e foram incluídos novos modelos, como o USMBOK, 
o que, juntamente com um capítulo específico sobre o impacto de novas 
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tecnologias, revigoraram o já muito completo e abrangente livro sobre Gover¬ 
nança de TI desses dois expoentes brasileiros. 

Para quem atua no ambiente acadêmico e empresarial, tenho certeza de 
que a leitura e o uso dos conceitos e conhecimentos declarados de forma pre¬ 
cisa, detalhada e organizada neste livro serão de grande valia. 

Prof. Dr. Ivanir Costa 

Professor do Programa de Mestrado 
e Doutorado em Engenharia de Produção da UNIP 
e professor do MBA em Gestão de Tecnologia da Informação da FIA 
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Introdução 


Fatores motivadores do livro 

O que pretendemos com este livro é fornecer orientação e um guia sobre o 
que é, de fato, a Governança de Tecnologia da Informação. 

Nossa conceituação vai um pouco mais além do que é debatido no mer¬ 
cado atualmente, que vê como Governança de TI a implantação de melhores 
práticas aplicáveis à TI. 

Procuramos trazer para este debate a necessidade de alinhar a TI ao negó¬ 
cio, tanto de forma estática, a partir das estratégias e dos planos de negócio 
da empresa, como dinamicamente, fazendo ajustes contínuos em virtude do 
surgimento de novas oportunidades de negócio, onde a TI é um ator impor¬ 
tante para a geração de valor para o negócio. 

Esta visão é importante, pois a TI é uma fonte de investimentos e despesas 
significativas para qualquer empresa que já atingiu uma dependência estraté¬ 
gica. Portanto, estar alinhada ao negócio passa a ser um imperativo para a TI, 
assim como, para algumas empresas, seguir regulamentos externos também 
passa a ser prioritário. 

Em virtude de escândalos corporativos de fraudes observados no passado e, 
mais recentemente, da crise financeira mundial de 2008/2009, há uma maior 
exigência por mecanismos de Governança Corporativa, no sentido de maior 
transparência das empresas. Adicionalmente, marcos de regulação externa (re¬ 
presentados principalmente por dispositivos como o Sarbanes-Oxley Act, o 
Acordo da Basileia II e as resoluções do Banco Central) têm trazido também 
maior complexidade para a gestão da TI. 
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Em suma, além de a TI ter que estar alinhada ao negócio, visando seu 
crescimento e perenidade, também é afetada por esses marcos de regula¬ 
ção, aos quais devem se submeter as empresas de capital aberto e que nego¬ 
ciam suas ações nas bolsas de valores norte-americanas, além das instituições 
financeiras. 

Acreditamos que, ao mostrarmos o caminho para o entendimento sobre o 
que é a Governança de TI, daremos nossa contribuição para o enriquecimen¬ 
to do tema, tentando sair um pouco do “debate tecnológico”, mas fazendo 
um equilíbrio entre o negócio , a tecnologia e, principalmente, a gestão da 
tecnologia da informação, e mostrando como a TI pode gerar valor para o 
negócio. 

Estamos cientes de que esta obra é um pequeno passo para que possamos 
obter melhor compreensão do que é a Governança de TI e das suas implica¬ 
ções para as organizações. 

Mostraremos, nesta nova edição, onde os vários modelos de melhores prá¬ 
ticas aplicados na área de Tecnologia da Informação se encaixam no “Ciclo 
da Governança de TI” proposto neste livro e como eles podem se relacionar. 
Acreditamos fortemente que cada organização deve usar as melhores práticas 
para desenvolver a sua própria arquitetura de processos de TI, de maneira 
adequada para a maturidade e o ambiente organizacional em que a TI está 
inserida. Abordaremos também a aplicação estendida do conceito de Go¬ 
vernança de TI para outras disciplinas e no contexto de novas tecnologias, 
tais como cloud computing, bigdata , mídias sociais e BYOD (bringyour own 
devicê). 

Sobre outro aspecto muito em voga atualmente, e que podemos cha¬ 
mar de “a nova geração de contratos de outsourcing , procuraremos explo¬ 
rar como os conceitos e componentes da Governança de TI se aplicam 
em um contexto dessa natureza, ou seja, como manter os princípios da 
Governança quando há vários fornecedores de serviços de TI atuando para 
a empresa. 

Por fim, relacionamos logicamente vários conceitos e abordagens, dando 
origem a um modelo proposto de Governança de TI, que é a base de nossa 
discussão em grande parte do livro. Procuramos tornar esse modelo o mais 
compreensível possível, cobrindo da estratégia à gestão dos processos e dos 
serviços de TI. 
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Objetivos do livro 

Os principais objetivos deste livro sáo: 

□ Conceituar de uma forma mais ampla a Governança de TI. 

□ Apresentar modelos de Governança de TI que possam ser aplicados 
em diferentes organizações e cenários. 

□ Mostrar onde as melhores práticas, tais como CobiT, ITIL, CMMI, 
ISO 27001 etc. se encaixam num processo de Governança de TI, 
evidenciando sua aplicabilidade. 

□ Apresentar a área de TI como uma Fábrica de Serviços, apoiada por 
diversos tipos de operações, alinhadas com o negócio. 

□ Apresentar a Governança de TI em cenários de outsourcing de siste¬ 
mas e serviços de TL 

□ Apresentar como se estrutura um programa de Governança de TI e 
também como ele é executado e gerenciado. 

□ Apresentar a importância da gestáo da mudança organizacional como 
fundamental para a implantação da Governança de TI na empresa ou 
instituição. 

□ Abordar a Governança de TI no contexto governamental. 

□ Abordar nossa visão sobre Governança de TI para pequenas e médias 
empresas. 

□ Abordar o impacto de algumas das novas tecnologias atuais na Go¬ 
vernança de TI. 

O livro procura responder às seguintes indagações usualmente feitas por 
parte de executivos de TI: 

□ O que é Governança de TI? 

□ Como eu alinho a TI ao negócio? 

□ Quais as melhores práticas que mais se adaptam para a minha empresa? 

□ Como as melhores práticas se relacionam? 

□ Quais os benefícios das melhores práticas? 

□ O que eu devo exigir dos meus fornecedores em termos de melhores 
práticas? 

□ Como eu implanto as melhores práticas na minha empresa? 
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Estrutura do livro 

O livro foi estruturado considerando uma abordagem dedutiva, que é uma 
característica dos autores, iniciando pela apresentação dos conceitos e funda¬ 
mentos da Governança de TI e de seus objetivos, domínios e componentes 
principais. 

Logo após, é discutido o impacto que marcos de regulação externos, tais 
como Sarbanes-Oxley , Basileia II e outros, têm sobre a gestão da tecnologia da 
informação. Grande parte das atenções dos Chief Information Officers (CIOs) 
tem sido dedicada a esses marcos. 

Em seguida, é apresentado um modelo genérico de Governança de TI, que 
serve de base para que façamos os encaixes necessários relativos às melhores 
práticas de gestão de TI. 

A partir desse modelo genérico, sustentado pelo que denominamos o “Ci¬ 
clo da Governança de TI”, fazemos um breve resumo de cada uma das me¬ 
lhores práticas que podem ser usadas nas diversas operações de serviços, como 
sistemas, segurança da informação, infraestrutura etc. 

O livro também discute como conduzir e estruturar a Governança de TI 
em um ambiente de outsourcing intensivo ou significativo. 

Finalizando, entendemos que cada empresa pode definir sua Governança 
de TI e que, uma vez tomada a decisão, a sua implementação é um programa 
composto por diversos projetos, cuja manutenção e melhoria devem ser siste¬ 
máticas e gerenciadas. 

Em relação à terceira edição, fizemos várias modificações, como os leitores 
poderão observar na estrutura do livro. A seguir, apresentamos uma sinopse 
dos capítulos. 

O objetivo do Capítulo 1 - Governança de TI é explorar o significado 
de Governança de TI, enumerando os seus objetivos, fatores motivadores e 
componentes constituintes, e mostrando como o cenário de negócios vem in¬ 
fluenciando a melhoria da gestão da tecnologia da informação pelas empresas. 

O Capítulo 2 - Governança Corporativa e Regulamentações de Com- 
pliance mostra onde a TI e sua gestão sofrem impacto da Governança Cor¬ 
porativa, de regulamentações de compliance externas e internas (mais precisa¬ 
mente do Sarbanes-Oxley Act, do Acordo da Basileia II e da Resolução 3380 
do Banco Central do Brasil), de sistemas de controle interno e sistemas de 
gestão corporativa de riscos. 
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O Capítulo 3-0 Modelo de Governança de TI apresenta um modelo 
de Governança de TI proposto, que denominamos IT Governance Extended 
Model e, baseado no Ciclo da Governança de TI e nos seus domínios, detalha 
cada um dos componentes, considerando questões como alinhamento estra¬ 
tégico da TI, plano de tecnologia da informação, mecanismos de tomada de 
decisão etc. 

O Capítulo 4 - Os Papéis da Governança de TI na Organização apre¬ 
senta como os papéis da Governança de TI se enquadram nas funções de uma 
área de TI, destacando as responsabilidades e abordagens para instituir meca¬ 
nismos de Governança de TI. 

O Capítulo 5 - Modelos de Melhores Práticas e o Modelo de Gover¬ 
nança de TI situa as principais melhores práticas difundidas no mercado, tais 
como CMMI, ITIL, CobiT, ISO, PMBOK, PRINCE2 etc. no modelo de 
Governança de TI, de uma forma geral e abrangente. 

O Capítulo 6 - Modelos Abrangentes de Governança de TI apresenta a 
norma ISO/IEC 38500 e o framework CobiT, evidenciando para cada mode¬ 
lo seu objetivo, sua estrutura, sua aplicabilidade e seus benefícios. 

O Capítulo 7 - Modelos para Gerenciamento de Serviços de TI apre¬ 
senta, brevemente, objetivos, estrutura, aplicabilidade e benefícios de modelos 
de referência orientados para o Gerenciamento de Serviços de TI, tais como 
a biblioteca ITIL - Information Technology Infrastructure Library (patrocinada 
pelo The Cabinet Office, do governo britânico), a norma ISO/IEC 20000, o 
CMMI for Services, o modelo brasileiro MR-MPS-SV (Serviços), o USM- 
BOK {Universal Service Management Body of Knowledge) e o MOF {Microsoft 
Operations Framework ). 

O Capítulo 8 - Modelos para Processos de Software apresenta, breve¬ 
mente, objetivos, estrutura, aplicabilidade e benefícios de modelos, tais como 
o Capability Maturity Model Integration - CMMI, o modelo MR-MPS e o 
metamodelo de processos de software representado pela ISO/IEC 12207. 

O Capítulo 9 - Modelos para Gerenciamento de Projetos apresenta, 
brevemente, objetivos, estrutura, aplicabilidade e benefícios dos modelos pa¬ 
trocinados pelo PMI {Project Management Institute) para gerenciamento de 
projetos (PMBOK), gerenciamento de programas e gerenciamento de portfó- 
lio, assim como da metodologia de gerenciamento de projetos denominada 
Projects in Controlled Environments 2 (PRINCE2), patrocinada pelo governo 
britânico, e do SCRUM. 



6 Implantando a Governança de TI - 4 a edição 


O Capítulo 10 - Segurança da Informação aborda as normas mais re¬ 
centes sobre Segurança da Informação, principalmente a ISO/IEC 27001 e a 
ISO/IEC 27002. 

O Capítulo 11 - Modelos para Gerenciamento de Sourcing aborda 
principalmente o modelo eSCM - ou The eSourcing Capability Model, tanto 
na visão do provedor de serviços como na do cliente, e o modelo CMMIfor 
Acquisition. 

O Capítulo 12 - Modelos para Disciplinas Complementares à Gover¬ 
nança de TI apresenta os modelos BPM CBOK, BABOK, Balanced Score- 
card , Seis Sigma, TOGAF e ISO 9001. 

O Capítulo 13 - Extensões e Derivações do Conceito de Governança 

de TI mostra a aplicação dos conceitos de Governança de TI de forma esten¬ 
dida, para disciplinas como Governança de Processos, Governança SOA e 
Governança de Dados. 

O Capítulo 14 - Novas Tecnologias e a Governança de TI aborda o im¬ 
pacto que algumas das novas tecnologias que estão começando a ser utilizadas 
no mercado - cloud computing, big data, mídias sociais e BYOD ( bringyour 
own devicê) - na Governança de TI. 

O Capítulo 15 - Governança de TI para Pequenas e Médias Empresas 

aborda quais devem ser as preocupações do responsável pela área de TI para 
implantar os conceitos de Governança de TI em uma organização de pequeno 
ou médio porte. 

O Capítulo 16 - Governança de TI para Governo aborda os requisitos e 
o ambiente de governo para a Governança de TI, discutindo notadamente as 
implicações da legislação de compras do Governo Federal, a Instrução Nor¬ 
mativa 04 do Ministério de Planejamento e Gestão e os principais acórdãos do 
Tribunal de Contas da União, que também impactam na implantação deste 
conceito em organizações governamentais da administração direta e indireta. 

O Capítulo 17 - Como Implantar a Governança de TI aborda os aspec¬ 
tos técnicos e organizacionais necessários à implementação de um Programa 
de Governança de TI na organização, considerando a sua estrutura, o seu pla¬ 
nejamento, o seu gerenciamento e a necessidade da gestão da governança de 
TI, assim como a importância do gerenciamento da mudança organizacional 
e da demonstração do valor da TI para o negócio. 

O Capítulo 18 - Estudos de Caso aborda, de forma sintética, casos de 
implantação da Governança de TI em algumas organizações no Brasil. 



D 


Governança de TI 


1.1 OS FATORES MOTIVADORES DA 
Governança de TI 

A Governança de TI é motivada por vários fatores (embora o senso comum 
considere a maior transparência da administração como sendo o principal 
motivador desse movimento que vemos no ambiente de TI das organizações), 
como podemos observar na Figura 1.1: 



Figura 1.1 - Fatores motivadores da Governança de TI 
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O ambiente de negócios no Brasil vem sendo caracterizado por: 


□ Intensa competição de novos entrantes no mercado. 

□ Surgimento de produtos e serviços substitutos. 

□ Novos concorrentes globais e de baixo custo. 

□ Barganha crescente de fornecedores e clientes. 

□ Ciclo de vida cada vez mais curto para os produtos e serviços. 

□ Novas ameaças devido à maior internacionalização da economia. 

□ Clientes mais conscientes e exigentes. 

□ Exigência de maior transparência nos negócios. 

□ Diversidade dos acionistas. 

□ Maior dinamismo dos requerimentos do negócio para TI. 

□ “Custo Brasil” ainda muito alto. 

□ Crescimento econômico do Brasil. 

□ Surgimento de uma nova classe média. 


Integrações tecnológicas, caracterizadas por: 


□ Integração das cadeias de suprimento, através de aplicações de supply- 
-chain e da infraestrutura de comunicação e Internet. 

□ Integração entre a gestão da empresa e o seu chão de fábrica, através 
de aplicações de Enterprise Resource Planning- ERP e de Manufactu- 
ring Execution System - MES. 

□ Integração entre as funções administrativas e padronização dos apli¬ 
cativos de back-office no contexto da empresa, de suas divisões e filiais 
através de ERP. 

□ Integração de redes de distribuição, tanto em termos de aplicativos 
como da infraestrutura de comunicação de dados. 

□ Integração dos processos de desenvolvimento de produtos com os 
processos de manufatura, através de aplicações de Product Life Cycle 
Management e de Product Data Management. 

□ Processos de gestão de clientes altamente sofisticados, através de apli¬ 
cativos de Customer Resource Management. 

□ Utilização de aplicações de BPM ( Business Process Management) e 
ECM ( Enterprise Content Management) como mecanismos de auto- 
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mação de processos de negócio, integrando em seus fluxos de traba¬ 
lho todos os sistemas e áreas funcionais da organização, tendo como 
perspectiva os processos de negócio transversais e a cadeia de valor. 

□ Integração da gestão estratégica com a gestão tática e operacional das 
empresas, através de aplicações de data warehouse, data mining e de 
inteligência organizacional. 

□ Utilização e análise de grandes volumes de dados não necessariamen¬ 
te estruturados, provenientes de várias fontes, visando gerar informa¬ 
ções úteis para a tomada de decisões estratégicas (no conceito de Big 
Data). 

As ilhas de sistemas de informação estão terminando. 

As integrações tecnológicas de processos através da tecnologia da informa¬ 
ção (aplicações e infraestrutura computacional e de comunicação de dados) 
fazem com que o risco que a TI representa para a continuidade do negócio 
seja altamente visível. É óbvio que tal risco deve ser mitigado e contingencia- 
do de uma forma sem precedentes e não imaginada até então. 

Lembramos que grande parte das melhores práticas aplicáveis à TI já está 
disponível há vários anos e somente a partir de 2005 os administradores “acor¬ 
daram” para a necessidade da boa gestão das atividades de TI. 

Até o mais desavisado dos administradores (aquele que não entende a TI 
da sua empresa) já percebeu o risco que é para o seu negócio uma TI mal 
gerenciada, pois provavelmente já precisou lidar com um incidente de indis- 
ponibilidade ou perda de dados de aplicações críticas. 


A segurança da informação impacta a integridade do negócio: 


□ No mundo interligado da Internet, a gestão de TI também ficou mais 
complexa e a infraestrutura de TI sofre riscos diários de intrusão vi¬ 
sando o “roubo” de dados e a disseminação de códigos maliciosos e 
vírus, o que pode afetar, sobremaneira, a operação da empresa. 

□ Conforme o nível de acesso dos vários pontos da empresa à “grande 
rede”, maior é a necessidade de envolver todos os níveis da organiza¬ 
ção na questão da gestão da TI e, em especial, na gestão da segurança 
da informação. 
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□ Tem sido cada vez mais frequente a necessidade de acesso a recursos 
de computação compartilhados, de rápido provisionamento e libera¬ 
ção, dentro do paradigma da computação em nuvem (cloud compu- 
ting ), gerando novos requisitos de segurança. 

□ A explosão da utilização das mídias sociais tem gerado novas pos¬ 
sibilidades de comunicação entre empresas e seus clientes, par¬ 
ceiros, fornecedores e colaboradores, exigindo maior flexibilidade 
e, ao mesmo tempo, controles mais efetivos em suas políticas de 
segurança. 

□ Cada vez mais as empresas estão facilitando a utilização de dis¬ 
positivos móveis próprios por parte de seus colaboradores (no 
conceito de BYOD ou bring your own devicé), requerendo con¬ 
troles mais robustos de acesso a informações, e-mails e aplicações 
corporativas. 


A dependência do negócio em relação à TI é caracterizada por: 


□ Quanto mais as operações diárias e as estratégias corporativas chaves 

dependem da TI, maior é o papel estratégico da TI para a empresa. 

□ Conforme a Figura 1.2: 

A Quando a TI tem alto impacto nas operações chaves (presente) 
e alto impacto nas estratégias chaves (futuro), diz-se que a TI é 
estratégica para o negócio. 

A Quando a TI tem alto impacto nas operações chaves e baixo im¬ 
pacto nas estratégias chaves, tem a conotação de uma Fábrica para 
o negócio, ou seja, o dia a dia do negócio depende da TI, mas o 
seu futuro não. 

A Quando a TI tem baixo impacto nas operações chaves e baixo im¬ 
pacto nas estratégias chaves, diz-se que ela está executando apenas 
tarefas de suporte, não sendo, do ponto de vista dos dirigentes, 
essencial para o negócio. 

A Quando a TI tem baixo impacto nas operações chaves e alto im¬ 
pacto nas estratégias chaves, diz-se que ela está exercendo um pa¬ 
pel de mudança, ou seja, está apoiando fortemente o direciona¬ 
mento futuro da organização. 
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Figura 1.2 - Impacto estratégico da tecnologia da informação 
Fonte: Lynda M. Applegate 


Marc os de regulação ( compliance ) representam restrições ao negócio, 
mas devem ser seguidos tendo em vista sua capacidade de atração de 
capital de risco, a um custo mais baixo, e de geração de lucros. 


□ O Sarbanes-Oxley Act determina que os relatórios financeiros e con¬ 
troles associados tenham fidedignidade e responsabiliza conjunta¬ 
mente diretores e o responsável pela área de finanças por atos lesivos 
aos acionistas e ao mercado. 

□ Isso significa, para a área de TI, que os aplicativos transacionais da 
empresa, geradores de fatos contábeis e financeiros, devem: 

A Ter disponibilidade para acesso e emissão de relatórios de resulta¬ 
dos financeiros e contábeis. 

A Armazenar os dados e as informações de forma adequada e com 
segurança. 
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A Ter a possibilidade de implementar trilhas de auditoria e verifica¬ 
ção de processos. 

A Ter os seus riscos (assim como os pertinentes à infraestrutura) 
conhecidos e gerenciados. 

□ O Acordo da Basileia II obriga os bancos a desenvolverem metodo¬ 
logias para a gestão de riscos operacionais e de crédito, a gerenciarem 
esses riscos e a publicarem essas metodologias em seus relatórios de 
resultados. Quanto melhores essas metodologias, menor é a necessi¬ 
dade de reserva quanto a perdas e, portanto, maior é a lucratividade 
do negócio: 

A Especialmente em bancos que apresentam um alto grau de inte¬ 
gração e sofisticação tecnológica (como no caso dos bancos brasi¬ 
leiros), a TI é um dos principais elementos de riscos operacionais; 
portanto, o gerenciamento de riscos é uma necessidade que deve 
estar presente na pauta do dia a dia dos Executivos de Negócio e 
dos CIOs dessas instituições. 


ATI como prestadora de serviços: 


□ O que os usuários esperam da TI? Projetos dentro do prazo e or¬ 
çamento, atendimento aos requisitos do negócio, disponibilidade 
das aplicações, disponibilidade da infraestrutura, capacidade para 
expandir o negócio, rápida resolução de incidentes e de serviços. 
Tudo isso requer postura e organização orientadas à prestação de 
serviços. 

□ Em grandes organizações brasileiras e multinacionais, está surgindo 
com bastante força a ideia de “centros de serviços compartilhados”, 
cujo objetivo é centralizar determinadas operações de TI (e também 
de algumas áreas de negócio), de forma a ganhar escala e prover ser¬ 
viços de TI para várias unidades ou divisões da mesma empresa ou 
empresas do mesmo grupo. 

□ O mesmo está ocorrendo com os chamados captive centers, que são 
centros de serviços focados que atendem a regiões inteiras, como por 
exemplo América Latina, Américas etc. 
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Para que conceitos como os de “centros de serviços compartilhados” e de 
captive centers funcionem de forma adequada, sáo necessários processos de TI 
eficazes e eficientes. Neste contexto, justifica-se a implantação de um Progra¬ 
ma de Governança de TI. 

1.2 0 que É a Governança de TI 

De acordo com o IT Governance Institute (2007b): 

A governança de TI é de responsabilidade da alta administração (incluin¬ 
do diretores e executivosj, na liderança, nas estruturas organizacionais e 
nos processos que garantem que a TI da empresa sustente e estenda as estra¬ 
tégias e os objetivos da organização. 

Outra definição é dada por Weill & Ross (2004): 

Consiste em um ferramentalpara a especificação dos direitos de decisão e res¬ 
ponsabilidade, visando encorajar comportamentos desejáveis no uso da TI. 

Para a ISO/IEC 38500 (ABNT, 2009), a Governança de TI “é o sistema 
pelo qual o uso atual e futuro da TI são dirigidos e controlados. Significa ava¬ 
liar e direcionar o uso da TI para dar suporte à organização e monitorar seu 
uso para realizar planos. Inclui a estratégia e as políticas de uso da TI dentro 
da organização”. 

Analisando essas definições, podemos concluir que a Governança de TI, 
como disciplina, busca o direcionamento da TI para atender ao negócio e o 
monitoramento para verificar a conformidade com o direcionamento tomado 
pela administração da organização. 

Portanto, a Governança de TI não é somente a implantação de mode¬ 
los de melhores práticas, tais como CobiT, ITIL, CMMI etc. 

Ainda dentro dessa ótica, a Governança de TI deve: 

□ Promover o alinhamento da TI ao negócio (suas estratégias e objeti¬ 
vos), tanto no que diz respeito a aplicações como à infraestrutura de 
serviços de TI. 
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□ Promover a implantação de mecanismos que garantam a continuida¬ 
de do negócio contra interrupções e falhas (manter e gerir as aplica¬ 
ções e a infraestrutura de serviços). 

□ Promover, juntamente com áreas de controle interno, compliance e 
gestão de riscos, o alinhamento da TI a marcos de regulação externos 
como a Sarbanes-Oxley (empresas que possuem ações ou títulos, pa¬ 
péis sendo negociados em bolsas de valores norte-americanas), Basi¬ 
leia II (no caso de bancos) e outras normas. 

Entretanto, a visão de Governança de TI que sugerimos vai além dessas de¬ 
finições e pode ser representada pelo que chamamos de “Ciclo da Governan¬ 
ça de TI ’ composto por quatro grandes etapas: (1) alinhamento estratégico 
e compliance, (2) decisão, (3) estrutura e processos e (4) gestão do valor e do 
desempenho. A Figura 1.3, a seguir, apresenta este ciclo. 



Figura 1.3-0 ciclo da Governança de TI 


O alinhamento estratégico e compliance refere-se ao planejamento estraté¬ 
gico da tecnologia da informação, que leva em consideração as estratégias da em¬ 
presa para seus vários produtos e segmentos de atuação, assim como os requisitos 
de compliance externos, tais como o Sarbanes-Oxley Act e o Acordo da Basileia. 

A etapa de decisão, compromisso, priorização e alocação de recursos 
refere-se às responsabilidades pelas decisões relativas àTI em termos de: arqui- 
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tetura de TI, serviços de infraestrutura, investimentos, necessidades de aplica¬ 
ções etc., assim como à definição dos mecanismos de decisão, ou seja, em que 
fóruns da empresa são tomadas essas decisões. 

Adicionalmente, trata da obtenção do envolvimento dos tomadores de 
decisão chaves da organização, assim como da definição de prioridades de 
projetos e serviços e da alocação efetiva de recursos monetários no contexto 
de um portfólio de TI. 

A etapa de estrutura, processos, operações e gestão refere-se à estrutura 
organizacional e funcional de TI, aos processos de gestão e operação dos pro¬ 
dutos e serviços de TI, alinhados com as necessidades estratégicas e operacio¬ 
nais da empresa. Nesta fase são definidas ou redefinidas as operações de siste¬ 
mas, infraestrutura, suporte técnico, segurança da informação, governança de 
TI e outras funções auxiliares ao CIO etc. 

A etapa de gestão do valor e do desempenho refere-se à determinação, 
coleta e geração de indicadores de resultados dos processos, produtos e servi¬ 
ços de TI, à sua contribuição para as estratégias e os objetivos do negócio e à 
demonstração do valor da TI para o negócio. 


1.3 Objetivos da Governança de TI 

O principal objetivo da Governança de TI é alinhar a TI aos requisitos do 
negócio, considerando soluções de apoio ao negócio, assim como a garantia 
da continuidade dos serviços e a minimização da exposição do negócio aos 
riscos de TI. 

Desdobrando este objetivo principal, podemos identificar outros objetivos 
da Governança de TI: 

□ Promover o posicionamento mais claro e consistente da TI em rela¬ 
ção às demais áreas de negócios da empresa: 

A Isso significa que a TI deve entender as estratégias do negócio e 
traduzi-las em planos para sistemas, aplicações, soluções, estrutura 
organizacional, processos e infraestrutura, desenvolvimento de com¬ 
petências, estratégias de sourcing e de segurança da informação etc. 

□ Promover o alinhamento e a priorização das iniciativas de TI com a 
estratégia do negócio: 
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A Isso significa que o que foi planejado para acontecer deve ser prio- 
rizado, tendo em vista as prioridades do negócio e as restrições de 
capital de investimento. 

A A priorizaçáo gera um portfólio de TI, que faz a ligação entre a 
estratégia e as ações do dia a dia. 

□ Promover o alinhamento da arquitetura de TI, sua infraestrutura 
e aplicações às necessidades do negócio, em termos de presente e 
futuro: 

A Isso significa implantar os projetos e serviços planejados e priorizados. 

□ Promover a implantação e melhoria dos processos operacionais e de 
gestão necessários para atender aos serviços de TI, conforme padrões 
que atendam às necessidades do negócio: 

A A execução dos projetos e serviços de TI deve ser realizada de 
acordo com processos operacionais (execução propriamente dita) 
e de gestão (planejamento, controle, avaliação e melhoria), que 
devem estar inseridos em uma estrutura organizacional, que, por 
sua vez, deve conter competências em pessoas e ativos usados para 
operar os processos. 

□ Prover a TI da estrutura de processos que possibilite a gestão do seu 
risco e compliance para a continuidade operacional da empresa: 

A Os processos definidos, tanto operacionais como gerenciais, de¬ 
vem considerar a mitigação de riscos para o negócio (por exem¬ 
plo: processos de segurança da informação, gestão de dados e apli¬ 
cações etc.). 

□ Promover o emprego de regras claras para as responsabilidades sobre 
decisões e ações relativas à TI no âmbito da empresa: 

A Isso significa identificar as responsabilidades sobre decisões 
acerca de princípios de TI, arquitetura de TI, infraestrutu¬ 
ra de TI, necessidades de aplicações, investimentos, segurança 
da informação, estratégia de fornecedores e parcerias, além de 
colocar em funcionamento um modelo de tomada de decisão 
correspondente. 
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1.4 Componentes da Governança de TI 

A Governança de TI compreende vários mecanismos e componentes que, 
logicamente integrados, permitem o desdobramento da estratégia de TI até a 
operação dos produtos e serviços correlatos. 

A Figura 1.4 mostra os componentes da Governança de TI dentro de cada 
etapa (ou domínio). 
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Figura 1.4 - Os domínios e componentes da Governança de TI 
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1.4.1 OS COMPONENTES DA ETAPA DE ALINHAMENTO 

Estratégico e Compliance 

O processo de alinhamento estratégico da tecnologia da informação pro¬ 
cura determinar qual deve ser o alinhamento da TI em termos da arquitetura, 
infraestrutura, aplicações, processos e organização com as necessidades pre¬ 
sentes e futuras do negócio. Este processo é executado no contexto do Plano 
de Tecnologia da Informação. 

Princípios de TI são regras que todos devem seguir, no âmbito da empresa, 
e que subsidiam tomadas de decisão acerca da arquitetura de TI, infraestru¬ 
tura de TI, aquisição e desenvolvimento de aplicações, uso de padrões, gestão 
dos ativos de TI etc. 

A gestão da demanda diz respeito à análise da dinâmica do negócio, em 
termos de padrões de atividades do negócio que indicam necessidades de no¬ 
vos serviços, melhoria dos serviços existentes, necessidade de mais capacidade 
em sistemas e infraestrutura, necessidades de inovação em negócios e tecnolo¬ 
gia e assim sucessivamente. 

As necessidades de aplicações dizem respeito às aplicações de TI que são 
necessárias para atender à continuidade e às estratégias do negócio. De¬ 
terminam também quais aplicações deverão ser mantidas, melhoradas, 
substituídas e implantadas. Nesse contexto, podem ser consideradas como 
aplicações: 

□ Sistemas transacionais. 

□ Sistemas de gestão. 

□ Aplicações de business intelligence. 

□ Dispositivos de segurança na captura de transações. 

□ Sistemas de controle de risco. 

□ Novos tipos de POS. 

□ Aplicação de tecnologias de reconhecimento biométrico. 

□ Aplicações de RFID ( Radio-Frequency IDentification). 

□ Aplicativos específicos desenvolvidos para dispositivos móveis etc. 

De acordo com Weill & Ross (2004), arquitetura de TI é: “a organização 
lógica para dados, aplicações e infraestrutura, representada por um conjunto 
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de políticas, relacionamentos e escolhas técnicas para buscar a integração de¬ 
sejada do negócio e da integração e padronização técnica.” 

A arquitetura foca na padronização de processos, dados e tecnologia de 
aplicações e é derivada dos princípios de TI, os quais são reflexos das estraté¬ 
gias de negócio e dos valores e credos da organização. 

A infraestrutura de 1T ainda de acordo com Weill & Ross (2004), é: “a 
fundação da capacidade planejada de TI (tanto técnica como humana) dis¬ 
ponível no âmbito de toda a organização como serviços compartilhados e 
confiáveis e usados por múltiplas aplicações”. 

A infraestrutura de TI liga a empresa a seus parceiros e fornecedores, assim 
como a infraestruturas externas, tais como bancos, redes privadas e Internet, 
e define: 

□ Os serviços de TI requeridos pelo negócio em termos de gestão de 
dados, comunicações, gestão de ativos de TI, gestão da infraestru¬ 
tura, segurança da informação, padrões de interfaces, educação em 
TI etc. 

□ Como esses recursos estarão dispostos na organização. 

□ Os recursos computacionais requeridos para apoiar o negócio. 

Os objetivos de desempenho direcionam a administração da TI para aten¬ 
der a metas de desempenho compatíveis com os objetivos traçados para a 
prestação dos serviços, enquanto os níveis de serviço são acordos estabelecidos 
com os clientes internos da empresa. Tanto os objetivos como os níveis de 
serviço orientam a administração da TI, o controle do dia a dia e também a 
forma como, a partir dos indicadores, podem ser realizadas as melhorias e até 
mesmo a reengenharia de processos. 

A capacidade de atendimento da TI define a quantidade de recursos huma¬ 
nos necessários para atender à demanda por sistemas e serviços, assim como 
a quantidade de recursos computacionais necessários, indicando se a infraes¬ 
trutura atual tem ou não condições de atendê-la. 

A estratégia de sourcing de serviços deve decidir sobre: 

□ O que passar para o sourcing. 

□ Como fazer o sourcing. 

□ Como escolher a melhor alternativa de parceria. 
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□ Como gerenciar os serviços do sourcing. 

□ Como gerenciar o desempenho dos fornecedores ou prestadores de 
serviços. 

□ Como fazer a transição de um modelo de operação para outro. 

□ Como fazer a transferência de um fornecedor para outro etc. 

A política de segurança da informação consiste na determinação de diretri¬ 
zes e ações referentes à segurança dos aplicativos, da infraestrutura, dos dados, 
pessoas e organizações (fornecedores e parceiros). 

Competências são as habilidades e os conhecimentos necessários para o 
desenvolvimento e a implantação das iniciativas de TI e que estarão presentes 
na estrutura organizacional e nos processos de serviços de TI. 

Processos e organização apresentam a forma como os serviços e produtos 
da TI serão desenvolvidos, gerenciados e entregues aos usuários e clientes e 
como a TI deve se organizar em termos funcionais. 

O Plano de Tecnologia da Informação consiste no principal produto 
do processo de alinhamento estratégico e deve contemplar informações 
sobre: 

□ Princípios de TI. 

□ Arquitetura de TI. 

□ Infraestrutura de TI. 

□ Necessidades de aplicações. 

□ Objetivos de desempenho e níveis de serviço e metas. 

□ Capacidade requerida de atendimento em relação a recursos huma¬ 
nos e infraestrutura. 

□ Organização das operações de serviços de TI. 

□ Estratégia para fornecedores de serviços. 

□ Competências requeridas. 

□ Políticas de segurança da informação. 

□ Investimentos e custeio. 

□ Roadmap de TI. 

O plano incorpora elementos que, uma vez documentados, permitem uma 
comunicação clara dos objetivos, produtos e serviços de TI para todos na or¬ 
ganização, conforme mostra a Figura 1.5. 
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Figura 1.5 - Componentes do Plano de Tecnologia da Informação 


1.4.2 OS COMPONENTES DA ETAPA DE DECISÃO, COMPROMISSO, 
Priorização e Alocação de Recursos 

Os mecanismos de decisão definem “quem decide o quê” em relação à TI 
dentro da organização em termos de: 

□ Princípios de TI. 

□ Arquitetura da informação. 

□ Infraestrutura de TI. 

□ Prioridades de aplicações. 

□ Investimentos em aplicações e infraestrutura. 

□ Política de segurança da informação. 

□ Estratégia de sourcing etc. 

Critérios de decisão são fundamentais para a priorização de investimentos 
e devem ser eminentemente institucionais, de forma que a alta administração 
possa decidir onde colocar o dinheiro, muito provavelmente alinhado aos 
objetivos e metas do negócio. 
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O portfólio de TI é uma metodologia para a priorização dos investimentos 
de TI com base no retorno de projetos e ativos para a organização e no seu 
alinhamento com os objetivos estratégicos do negócio. 

Além do mais, o portfólio de projetos: 

□ Torna claras as regras de priorização de projetos e ativos. 

□ Faz com que a administração saiba onde deve investir. 

1.4.3 OS COMPONENTES DA ETAPA DE ESTRUTURA, PROCESSOS, 
Organização e Gestão 

Os projetos alocados (nos quais a TI não é o gestor) ou sob responsabilida¬ 
de de TI são planejados, executados, gerenciados e implantados. São projetos 
de implantação de sistemas integrados de gestão, desenvolvimento e manu¬ 
tenção de sistemas, infraestrutura, arquitetura, segurança da informação, im¬ 
plantação de processos de TI etc. 

Os serviços são operações onde acontece o atendimento da TI 1 no forneci¬ 
mento de serviços aos usuários, gestores e, possivelmente, clientes da organi¬ 
zação, fornecedores, parceiros etc. 

Nesta etapa um conjunto de atividades operacionais e gerenciais é regido 
por processos de TI, oriundos de melhores práticas, inserido em funções or¬ 
ganizacionais no contexto de uma divisão de trabalho. 

As principais operações de serviços de TI são: 

□ Operações de sistemas : contemplam desenvolvimento e manutenção 
de sistemas. 

□ Operações de suporte técnico : contemplam atendimento a usuários 
no uso dos softwares e infraestrutura da instalação. 

□ Operações de infraestrutura : contemplam serviços de infraestrutura 
de TI, suporte de TI, gestão de ativos de software, entrega de serviços 
e suporte a serviços. 

□ Operações de segurança da informação : contemplam serviços de plane¬ 
jamento da segurança da informação e o monitoramento diário de riscos 
ao ambiente computacional da organização e a seus dados, bem como 
atividades de conscientização, treinamento e educação para a segurança. 


1 O conceito de serviços adotado por nós é mais amplo, abrangendo todos os serviços de TI, desde 
o atendimento a uma solicitação de manutenção de sistemas ou um novo projeto de sistemas até os 
serviços associados à infraestrutura de TI. 
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□ Operações de suporte ao CIO : contemplam atividades de planeja¬ 
mento da TI, orçamento da TI, gerenciamento de contratos, geren¬ 
ciamento de fornecedores, escritório de projetos e inovação tecnoló¬ 
gica para negócios etc. 

□ Operações de Governança de TI : contemplam atividades para a pro¬ 
moção da implantação das melhores práticas na execução dos ser¬ 
viços de TI, seu planejamento, monitoramento, gestão e melhoria 
contínua. 

□ Operações de processos : consiste em projetos de elaboração, melhoria 
e implantação de processos de negócio e também o desenho de inova¬ 
ções nos processos de negócio. 

□ Operações de arquitetura de TI: consiste em atividades de planeja¬ 
mento e definição de arquiteturas de TI, notadamente de software, 
infraestrutura tecnológica e de aplicações e de serviços. 

□ Outras operações : serviços de garantia da qualidade, grupo de enge¬ 
nharia de software, grupo de gerenciamento da configuração, grupo 
de novas tecnologias e outras que dependem do tipo da operação 
requerida pela organização, comuns em empresas que trabalham com 
vários produtos do tipo “informação intensiva”, como é o caso das 
instituições financeiras. 

A implantação de inovações ocorre tanto no nível dos processos de negó¬ 
cio (nova forma de executar um processo de negócio de maneira mais dife¬ 
renciada ou com menor custo, comparativamente à concorrência, agregando 
mais valor na percepção do cliente) como na tecnologia aplicada aos serviços, 
como, por exemplo, inovações em detecção de intrusão na rede e inovações 
aplicadas na automação de processos de negócio, como o reconhecimento 
biométrico. 

O relacionamento com o cliente trata da interação dos usuários internos 
ou externos com a área de TI, abrangendo processos que devem definir: 

□ Como o cliente solicita o serviço. 

□ Quem pode solicitar o serviço. 

□ Como os serviços são avaliados. 

□ Quais são os canais de comunicação. 

□ Como as responsabilidades são atribuídas em projetos, entre os usu¬ 
ários e a TI. 
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□ Como a TI é capacitada para atender aos usuários e ao negócio e como 
os usuários sáo capacitados sobre o uso da TI. 

□ Como os projetos sáo desenvolvidos em conjunto com o cliente etc. 

O relacionamento com os íornecedores , analogamente ao modelo de re¬ 
lacionamento com o cliente, trata dos seguintes aspectos da operaçáo de TI: 

□ Como as solicitações sáo encaminhadas para os fornecedores. 

□ Como o fornecedor responde à solicitação. 

□ Como os acordos de níveis operacionais 2 e contratos de apoio 3 sáo 
controlados. 

□ Como a qualidade dos serviços é avaliada e melhorada. 

□ Como o desempenho do fornecedor é controlado etc. 

1.4.4 O COMPONENTE DA ETAPA DE GESTÃO DO VALOR E DO 

Desempenho da TI 

A gestão do valor da TI refere-se às atividades conduzidas para que a TI 
demonstre o seu valor para o negócio em termos de custos relativos, transfor¬ 
mação do negócio e apoio à estratégia do negócio e as medições decorrentes. 

A gestão do desempenho refere-se ao monitoramento dos objetivos de de¬ 
sempenho das operações de serviços em termos de desenvolvimento de aplica¬ 
ções, suporte a serviços, entrega de serviços, segurança da informação e o seu 
monitoramento, assim como dos acordos de níveis de serviço, acordos de níveis 
operacionais e níveis de serviços dos contratos de apoio. 


2 Em inglês, os acordos de níveis operacionais são conhecidos pela sigla OLA (Operational Levei 
Agreements), que compreendem os acordos de níveis de serviço entre as áreas de TI e entre esta e as 
áreas de suprimento e contratos da empresa. 

3 Contratos de apoio são realizados com fornecedores externos de serviços e são conhecidos como UC 
(Underpinning Contracts). 







Governança Corporativa e 
Regulamenta ções de Compliance 


Como vimos no início deste livro, a TI deve atender às necessidades do 
negócio e também a marcos de regulação externos. 

Em organizações que apresentam um grau de Governança Corporativa 
mais avançada, a Governança de TI tem grande interação com sistemas de 
controle interno e de gestão de riscos corporativos. 

Dependendo do negócio, existem vários marcos reguladores. Por exemplo, 
uma empresa de telecomunicações no Brasil deve atender a uma série de instru¬ 
mentos regulatórios provenientes da Anatei. O mesmo ocorre com os bancos, em 
relação às normas do Banco Central ou com as organizações que possuem ações 
na BMF-Bovespa, em relação às normas da Comissão de Valores Mobiliários. 

De qualquer forma, essas regulamentações geralmente são transformadas 
em objetivos e entidades de controle no contexto da Governança Corporativa. 


2.1 Governança Corporativa e a ligação com a 
Governança de TI 

De acordo com o Instituto Brasileiro de Governança Corporativa - IBGC 
(2009), a Governança Corporativa consiste: 

no sistema pelo qual as sociedades são dirigidas, monitoradas e incentivadas, 
envolvendo o relacionamento entre proprietários, Conselho de Administra¬ 
ção, Diretoria e órgãos de controle interno. As boas práticas de governança 
corporativa convertem princípios em recomendações objetivas alinhando 
interesses com a finalidade de preservar e otimizar o valor da organização, 
facilitando seu acesso ao capital e contribuindo para a sua longevidade. 
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Os princípios da Governança Corporativa, ainda de acordo com IBGC 
(2009), sáo: 

□ Transparência: obrigação e desejo de informar resultados e ações. 

□ Equidade: tratamento igual para todos os acionistas. 

□ Prestação de contas: os agentes da governança corporativa prestam 
contas e são responsáveis pelos seus atos e omissões. 

□ Responsabilidade corporativa: os agentes de governança devem ze¬ 
lar pela sustentabilidade das organizações, visando a sua longevidade, 
incorporando considerações de ordem social e ambiental na definição 
dos negócios e operações. 

A Figura 2.1 apresenta, de acordo com o IBGC, o Sistema de Governança 
Corporativa. 



Figura 2.1 - Sistema de Governança Corporativa 
Adaptado de IBGC (2009) 
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Para garantir que os princípios da Governança Corporativa sejam efetivos, 
seja por sua vontade expressa ou requerida face ao ambiente regulatório em 
que se encontra, as organizações lançam mão de modelos de controle interno 
e gestão de risco. 

O principal modelo norteador da estruturação de sistemas de controles in¬ 
ternos e de gestão de risco é o COSO - The Committee ofSponsoring Organiza- 
tions ofthe Treadway Commission (Comitê das Organizações Patrocinadoras). 

O COSO é uma entidade sem fins lucrativos dedicada à melhoria dos rela¬ 
tórios financeiros através da ética, efetividade dos controles internos e gover¬ 
nança corporativa, que foi criada por iniciativa do setor privado para estudar 
as causas de ocorrências de fraudes em relatórios financeiros e contábeis e 
desenvolver recomendações para empresas de capital aberto e para instituições 
de ensino. 

Em 1992, o COSO publicou um trabalho intitulado Internai Control — In- 
tegrated Framework (Controle Interno - Um Modelo Integrado), que se tor¬ 
nou referência para as organizações do mundo todo para que elas estruturem 
seus sistemas de controle interno. 

De acordo com o COSO, o controle interno é um processo efetuado pelo 
conselho de administração, executivos ou qualquer outro funcionário de uma 
organização, com a finalidade de possibilitar o máximo de garantia nas se¬ 
guintes categorias de objetivos: 

□ Eficiência e eficácia das operações: salvaguarda de seus ativos e pre¬ 
venção e detecção de fraudes e erros. 

□ Confiabilidade das demonstrações financeiras: exatidão, integrida¬ 
de e confiabilidade dos registros financeiros e contábeis. 

□ Conformidade com as leis e regulamentos vigentes: aderência às 
normas administrativas, às políticas da empresa e à legislação à qual 
está subordinada. 

Em 2001, o COSO iniciou um projeto para a determinação de um mo¬ 
delo de Risco Corporativo, que resultou no documento intitulado Enterprise 
Risk Management Framework , ampliando o alcance dos controles internos e 
definindo processos para o gerenciamento de riscos corporativos. 

A Figura 2.2 mostra como esses sistemas de controle e risco e de direitos 
decisórios da Governança Corporativa criam as restrições de operação dos 
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serviços e projetos de TI. Por exemplo, supondo que o sistema de controle de 
riscos aponta que é um risco náo haver um método de gerenciamento de pro¬ 
jetos de TI; a TI deve então implementar este método (controle interno), em 
relação ao qual o sistema de controle interno irá verificar a aderência perio¬ 
dicamente, ou seja, realizará uma auditoria para verificar se os projetos estão 
aplicando, de fato, o método. 



Figura 2.2 - Integração Governança Corporativa x Governança de TI 


Nesse contexto, há dois regulamentos bastante fortes, que têm dado um 
grande poder de fogo às áreas de “controle interno” da maioria das organiza¬ 
ções: o Sarbanes-Oxley Act e o Acordo da Basileia II. 

O primeiro atinge empresas de capital aberto e que têm ações nas bolsas 
de valores norte-americanas. No Brasil, atinge algumas empresas de capital 
majoritariamente nacional e as subsidiárias de empresas transnacionais. 

A segunda atinge instituições financeiras de uma forma geral. É uma regu¬ 
lamentação patrocinada pelo Bank for International Settlements ou BIS, que 
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seria o “Banco Central dos Bancos Centrais”, com sede na cidade de Basileia, 
na Suíça. A partir dela, as autoridades bancárias principais de vários países 
criaram modelos derivados (no caso do Banco Central do Brasil, temos a Re¬ 
solução 3380, também abordada neste capítulo). 

Ambas as regulamentações têm forte impacto na área de TI e fazem parte 
do nosso modelo de Governança de TI, pois, dependendo da organização, 
devem ser contempladas pelo alinhamento estratégico. Seu atendimento se re¬ 
veste de vários projetos constantes do portfólio de TI, que váo criar restrições 
às operações de serviços de TI. 

Agora vamos explorar um pouco mais as implicações desses marcos de 
regulação externos. 


2.2 Entendendo as implicações do Sarbanes- 
Oxley Act 

2.2.1 O que É o Sarbanes-Oxley Act e qual a sua 

FINALIDADE 

Os motivadores do Sarbanes-Oxley Act (vide Sarbanes & Oxley 2002), 
como é conhecido no mundo dos negócios, foram os escândalos financei¬ 
ros acontecidos em companhias abertas nos Estados Unidos como a Enron 
e outras, que minaram a confiança dos investidores no mercado de capital 
americano (em especial dos que investiam em ações dessas companhias nas 
bolsas de valores). Para quem não sabe, a bolsa de valores é o principal meio 
de investimento da maioria das famílias norte-americanas. Portanto, manter 
a credibilidade do “sistema” é vital para os legisladores americanos e para os 
responsáveis pela conduçáo econômica dos Estados Unidos. 

Os objetivos principais dessa lei sáo proteger os investidores do mercado de 
capitais americano de fraudes contábeis e financeiras de companhias abertas, 
assim como instituir uma série de penalidades contra crimes relacionados. Seu 
foco é sobre “controles internos sobre relatórios financeiros”. 

De acordo com Ramos (2004): 

O termo “controle interno sobre relatórios financeiros” é definido como 
o processo projetado por, ou sob a supervisão do principal executivo e do 
principal responsável por finanças do emitente, ou pessoas que desempe- 
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nham funções similares, efetivados pelo comitê de diretores do emitente, 
pela gerência ou outras pessoas, para prover garantia razoável relacionada 
à confiabilidade de emissão de relatórios financeiros e a preparação de 
relatórios de resultados financeiros para propósitos externos, de acordo com 
princípios de contabilidade geralmente aceitos - GAAP. Inclui política e 
procedimentos para: 

(1) Manter registros que, em razoável detalhe, com exatidão e de forma 
correta, reflitam as transações e disposições dos ativos do emitente. 

(2) Prover garantia de que as transações sejam registradas quando neces¬ 
sário para permitir a preparação de declarações de resultados financeiros 
de acordo com princípios contábeis geralmente aceitos, e que as receitas e 
despesas do emitente sejam feitas somente de acordo com autorizações da 
gerência e diretores do emitente. 

(3) Prover garantia relacionada à prevenção ou detecção, no momento 
preciso, de aquisições não autorizadas, uso ou disposição dos ativos do 
emitente que possam ter um efeito material nas declarações dos resultados 
financeiros. 

O nome dessa lei federal americana, patrocinada pelos congressistas norte- 
-americanos Sarbanes e Oxley e publicada em agosto de 2002 para regular 
as responsabilidades e práticas de auditoria em empresas abertas, é: “Public 
Accounting Reform andInvestor Protection Act”. 

A Stock Exchange Comission - SEC (que vem a ser a equivalente à nossa 
Comissão de Valores Mobiliários - CVM), autoridade que regula o mercado 
de capitais norte-americano, tem a responsabilidade por estabelecer as regras 
para implantar o Sarbanes-Oxley Act. Tais regras incluem guias para a elabora¬ 
ção de relatórios financeiros pelos CEO (Chief Executive Ojficer- geralmente 
o presidente da empresa) e o CFO {Chief Financial Ojficer - responsável má¬ 
ximo pelas finanças de uma empresa). 

Para definir regras para os auditores independentes a respeito da lei, foi 
criada no contexto da SEC o Public Company Accounting Oversight Board, que 
é uma organização náo governamental dedicada a criar normas a partir da lei. 

O SOX {Sarbanes-Oxley Act) é composto pelos seguintes títulos: 

□ Título I : Public Company Accounting Oversight Board. Trata do 
PCAOB, que é uma organização náo governamental que deve regis- 
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trar as auditorias e estabelecer os padrões de auditoria relativos aos 
controles financeiros das empresas abertas. 

□ Título II: Auditor Independence. Estabelece que os auditores sejam 
independentes e que haja rotatividade entre empresas de auditoria. 

□ Título III: Corporate Responsibility. Atribui as responsabilidades cor¬ 
porativas, em termos da formação de um comitê de auditoria, da 
sua composição e dos requisitos sobre o envio de relatórios à SEC 
e outros tipos de conduta requeridos dos CEOs, CFOs e demais 
diretores. 

□ Título IV: Enhanced Financial Disclosures. Estabelece novas regras 
para a elaboração e publicação de resultados financeiros, assim como 
requer que a administração mantenha um sistema de controle inter¬ 
no adequado. 

□ Título V: Analyst Conflicts oflnterest. Estabelece regras para que não 
haja conflitos de interesse na atuação de analistas de corretoras de 
valores ou de administração de fundos. 

□ Título VI: Comission Resources and Authority. Estabelece regras para 
autorização de fundos para a SEC, assim como a autoridade da SEC 
para suspender, temporariamente ou não, empresas e profissionais de 
auditoria. 

□ Título VII: Studies and Reports. Aqui o SOX autoriza a SEC a efetuar 
estudos e relatórios relativos à consolidação de firmas de auditoria, 
agências de “ rating de risco, violações profissionais no âmbito do 
mercado de capitais, análises dos resultados das ações da SEC e estu¬ 
dos de bancos de investimentos. 

□ Título VIII: Corporate and Criminal FraudAccountability. Estabelece 
regras específicas e penalidades para a destruição de registros corpora¬ 
tivos, assim como para alteração de dados e falsificações. 

□ Título IX: White-Collar Crime Penalty Enhancements. Contém pena¬ 
lidades para crimes do colarinho branco. 

□ Título X: Corporate Tax Returns. Estabelece que o CEO deve, obriga¬ 
toriamente, assinar o imposto de renda da pessoa jurídica. 

□ Título XI: Corporate Fraud Accountability. Define a responsabilidade 
corporativa pela comunicação de informações financeiras de resulta¬ 
dos fraudulentos. 
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2.2.2 Requisitos do SOX que afetam a TI 

Para a TI, as seções 302 e 404 do SOX são de especial importância. 

A seção 302 especifica que: 

□ O CEO e o CFO devem revisar os relatórios financeiros. 

□ Com base no conhecimento do CEO e do CFO, os relatórios não 
contêm nenhuma declaração falsa de um fato material ou omissão, 
para fazer a declaração de resultados. 

□ Com base no conhecimento do CEO e do CFO, outras informações 
financeiras incluídas representam corretamente, em todos os aspectos 
materiais, a condição financeira, resultados de operações e fluxos de 
caixa nos períodos representados pelos relatórios. 

□ O CEO e o CFO são responsáveis por manter e estabelecer controles 
e procedimentos sobre a emissão de relatórios financeiros e controles 
internos sobre tais relatórios. 

□ Os sistemas de controle interno sobre a emissão de relatórios finan¬ 
ceiros devem ser projetados sob a supervisão do CEO e do CFO, 
incluindo as subsidiárias. 

□ Os sistemas de controle internos sobre relatórios financeiros também 
devem ser projetados sob a supervisão do CEO e do CFO. 

□ Deve ser avaliada a efetividade do sistema de controle sobre a emissão 
de relatórios financeiros. 

□ Devem ser comunicadas mudanças nos controles internos sobre rela¬ 
tórios financeiros, considerando o último ano fiscal. 

□ Devem ser comunicadas as deficiências dos sistemas de controle in¬ 
terno que possam afetar a habilidade da empresa em registrar, proces¬ 
sar, sumarizar e comunicar informações financeiras. 

□ Deve ser comunicada qualquer fraude que envolva a gerência ou ou¬ 
tros empregados que tenham um papel significante nos registros do 
controle interno sobre relatórios financeiros. 

A Seção 404, por sua vez, especifica que: 

□ A administração tem a responsabilidade de estabelecer e manter uma 
estrutura adequada de controle interno e procedimentos para relató¬ 
rios financeiros. 
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□ A administração deve avaliar a efetividade do sistema de controle in¬ 
terno sobre relatórios financeiros. 

□ Deve ser realizada uma auditoria externa específica sobre a avalia¬ 
ção interna da efetividade do sistema de controle interno feita pela 
administração. 

Para atender aos requisitos do SOX, as informações financeiras sobre os 
resultados devem atender aos seguintes princípios: 

□ O conteúdo da informação deve ser apropriado. 

□ A informação deve estar disponível no momento em que for necessária. 

□ A informação é atual ou pelo menos a última disponível. 

□ Os dados e as informações estão corretas. 

□ A informação é acessível aos usuários interessados. 

□ Há um sistema de controle interno sobre relatórios financeiros que 
garante todos os demais itens anteriores. 

Esses requisitos afetam a TI de forma bastante significativa. Lembramos 
que as informações financeiras e de resultados são oriundas de todos os pro¬ 
cessos de negócio que geram fatos contábeis e financeiros para a empresa, e 
que podem estar automatizados ou não. 

Portanto, praticamente todos os sistemas transacionais de uma empre¬ 
sa relativos a pagamento de pessoal, pagamento de benefícios a pessoal, 
transações com fornecedores (compras, aplicação de recursos financeiros) e 
clientes (vendas, captação de recursos financeiros), com acionistas, com o 
governo, gestão de recursos financeiros etc. devem ser considerados quando 
pensamos no SOX. 

No contexto de um sistema de controle interno, os riscos são identifi¬ 
cados e mitigados, os controles são estabelecidos e executados, os registros 
e sistemas de controle são desenvolvidos e mantidos e toda a sistemática é 
monitorada. 

A TI, como sabemos, é um elemento crítico como fonte de risco para a 
continuidade do negócio e para o atendimento ao SOX. 

A Tabela 2.1 mostra as principais implicações operacionais do SOX para a 
TI, considerando os processos de TI (vide em capítulos posteriores as consi¬ 
derações dos modelos de melhores práticas de TI): 
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Requisitos de qualidade 
da informação 

Implicações do SOX 

0 conteúdo da informação 
deve ser apropriado. 

• Processo de desenvolvimento de requisitos de software. 

• Processo de gerenciamento de requisitos de software. 

• Métodos de engenharia de software. 

• Processos de verificação (teste). 

• Processos de validação (aceitação pelos usuários). 

• Processos de segurança da informação empregados nos aplicativos. 

• Processos de aceitação de produtos de terceiros. 

• Processo de gestão da mudança e da configuração. 

A informação deve estar 
disponível no momento em 
que for necessária. 

• Disponibilidade de aplicativos. 

• Disponibilidade da infraestrutura. 

• Gerenciamento de incidentes e problemas no ambiente de produção. 

• Suporte aos usuários. 

• Gestão de aplicativos e de ativos de TI. 

• Processos de gerenciamento da infraestrutura. 

• Segurança da infraestrutura. 

• Gerenciamento da contingência. 

• Gerenciamento de disponibilidade e desempenho. 

A informação é atual ou pelo 
menos é a última disponível. 

• Processos de gerenciamento de dados. 

• Planejamento e gerenciamento da contingência e de desastres. 

• Segurança da informação na infraestrutura. 

Os dados e as informações 
estão corretas. 

• Segurança da informação em aplicativos. 

• Segurança da infraestrutura de TI. 

• Teste de software. 

• Controle da mudança e da configuração. 

• Gerenciamento de ciados. 

• Gerenciamento de requisitos. 

A informação é acessível aos 
usuários interessados. 

• Segurança da informação referente a controle de acessos e privilégios. 

• Controle de autorizações. 

Há um sistema de controle 
interno sobre relatórios 
financeiros. 

• Avaliação de riscos de TI. 

• Gestão da qualidade. 

• Planos de desastres e recuperação. 


Tabela 2.1 - Implicações do SOX para TI 


2.2.3 Impacto do SOX na Governança de TI 

O SOX impacta a Governança de TI no que diz respeito aos seguintes 
aspectos: 

□ As questões relativas ao SOX devem ser tratadas no Plano de Tecno¬ 
logia da Informação. 












Governança Corporativa e Regulamentações de Compliance 35 


□ Novos controles (funcionalidades) em aplicações do legado devem ser 
implantados. 

□ Novas aplicações devem ser implantadas. 

□ Processos de TI existentes devem ser ajustados e melhorados para mi¬ 
tigar riscos. 

□ Novos processos de TI devem ser projetados e implantados. 

□ Ocorrência de prováveis mudanças na estrutura organizacional de TI 
em função dos processos ajustados e também dos novos. 

□ Novos indicadores de desempenho deverão ser definidos e 
implantados. 

□ Os riscos de TI devem ser monitorados constantemente. 

Finalizando este tema, o CIO deve ser peça fundamental no esforço da 
empresa para se ajustar ao SOX, devendo participar ativamente do projeto de 
adequação. 


2.3 Entendendo as implicações do Acordo da 
Basileia II 

2.3.1 O que É o Acordo da Basileia II 

Estabelecido pelo Bank for International Settlements , BIS, sediado na cida¬ 
de suíça da Basileia (que vem a ser o “Banco Central dos Bancos Centrais”), 
o Acordo da Basileia II (vide BIS 2001) estipula requisitos de capital mínimo 
para as instituições financeiras, em função dos seus riscos de crédito e opera¬ 
cionais. O acordo possui três pilares: 

□ O primeiro pilar estabelece regras e procedimentos para cálculo dos 
requisitos de capital, tendo em vista os riscos de crédito e operacio¬ 
nais, de acordo com a aplicação de abordagens distintas de avaliação e 
mitigação de riscos. Risco de crédito é a perda econômica sofrida pela 
incapacidade voluntária ou involuntária do tomador do crédito em 
atender às suas obrigações contratuais no tempo requerido. No caso 
dos bancos, a metodologia deve atender tanto a uma transação indi¬ 
vidual de crédito como a uma carteira de crédito, ou seja, o portfólio 
de crédito da instituição. Risco operacional, por sua vez, é o risco de 
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perdas financeiras diretas ou indiretas resultantes de processos internos 
inadequados, de falhas nos processos, pessoas e sistemas, ou mesmo de 
eventos externos. 

□ O segundo pilar estabelece regras para que os Bancos Centrais de cada 
país executem auditorias nas instituições financeiras, visando avaliar 
a aplicação dos métodos de gestão de risco e a avaliação e mitigação 
de riscos de crédito e operacionais, assim como a emissão de infor¬ 
mações para o mercado acerca da exposição do risco da instituição. 

□ O terceiro pilar estabelece regras para a comunicação para o mercado, 
dos requisitos mínimos de capital, face aos riscos e aos métodos e resul¬ 
tados de avaliações de riscos, conforme estabelecido pelo primeiro pilar. 


2.3.2 Implicações do Acordo da Basileia II sobre a TI 

Atualmente o Banco Central do Brasil vem auditando as áreas de TI dos 
bancos através do instrumento denominado CobiT, desenvolvido pela In¬ 
formation Systems Audit and Control Association - ISACA (este frameivork é 
apresentado mais adiante). 

Como os bancos no Brasil estão em estágio extremamente avançado no 
que diz respeito à integração, uso de tecnologias, diversidade de canais e di¬ 
versidade de produtos, a questão “risco operacional” de TI é primordial. A TI 
é um dos principais elementos do risco operacional de um banco, juntamente 
com pessoas e processos de negócio. 

No que tange ao risco operacional, o impacto do Acordo da Basileia abrange 
praticamente todo o espectro de processos de TI e respectivas áreas organizacionais. 

Do ponto de vista do risco de crédito, o impacto recai sobre: 

□ Capacidade de armazenamento de dados em face da granularidade 
de informações requeridas de cada cliente, visando avaliar riscos de 
forma mais consistente. 

□ Integridade das informações acerca das transações do banco. 

□ Integridade das informações armazenadas sobre os clientes e opera¬ 
ções de crédito. 

□ Segurança dessas informações. 

□ Contingências na operação. 

□ Planejamento de capacidade. 
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□ Planejamento de desastre e recuperação. 

□ Integridade do processo de emissão de relatórios requeridos pelo BIS. 

Analogamente ao que falamos no caso do SOX, relativamente ao Acordo 
da Basileia, o CIO ou equivalente deve: 

□ Inserir as questões do acordo em seu Plano de Tecnologia da 
Informação. 

□ Implantar novos processos de TI. 

□ Ajustar ou melhorar processos existentes. 

□ Ajustar a estrutura organizacional de TI para acomodar novos processos. 

□ Definir e implantar novos indicadores de desempenho, caso seja 
necessário. 

□ Tratar a gestão de riscos (planejamento e monitoramento) de TI 
como seu processo com identidade própria na organização de TI. 


2.4 O impacto da Resolução 3380 do Banco 
Central do Brasil 

Em junho de 2006 foi publicada a Resolução 3380 do Banco Central do 
Brasil, que determina que as instituições financeiras e demais instituições au¬ 
torizadas a funcionar pelo Banco Central implementem sua própria estrutura 
de gerenciamento de risco. 

Conforme definição na resolução, risco operacional é a possibilidade de 
ocorrência de perdas resultantes de falha, deficiência ou inadequação de pro¬ 
cessos internos, pessoas e sistemas, ou de eventos externos. No que tange à 
tecnologia da informação, a resolução refere-se a falhas em sistemas como 
risco operacional. Alguns riscos apontados, tais como interrupção de ati¬ 
vidades da instituição e danos a ativos, também podem ser originados pela 
tecnologia da informação. 

De acordo com a resolução, deve-se identificar, avaliar, monitorar, contro¬ 
lar e mitigar os riscos da instituição: 

□ Os riscos operacionais devem ser identificados, avaliados, monitora¬ 
dos, controlados e mitigados (essa gestão deve ser permanentemente 
executada). 
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□ Planos de continuidade de negócios devem ser elaborados, testados e 
atualizados. 

□ Os riscos dos fornecedores de serviços devem ser gerenciados. 

O ponto de partida utilizado pela maioria das instituições é a avaliação dos 
riscos de TI com base nos processos do CobiT (leia no capítulo 6 maiores 
detalhes sobre este modelo). 

Outra abordagem é a elaboração de mapas de riscos por negócio, onde 
os riscos que a TI oferece para o negócio são identificados, avaliados, mo¬ 
nitorados, controlados e mitigados. Um exemplo de risco em um processo 
de internet banking é a disponibilidade das aplicações; o mesmo ocorre para 
uma transferência eletrônica de fundos. Dependendo da criticidade do risco 
para o negócio, é determinada a frequência para a ocorrência das auditorias 
sobre TL 

Nesse contexto, quem realiza a gestão de riscos é uma área de gestão de 
riscos corporativos, cujas informações devem ser tratadas pela TI para projetar 
e implementar ações de mitigação (controles internos de TI). 

Por exemplo, em processos críticos de negócios, geralmente são elaborados 
Planos de Continuidade do Negócio, que irão resultar na elaboração de Pla¬ 
nos de Desastre e Recuperação pela TI, visando recuperar serviços de TI que 
apoiam o processo de negócio. 

O mais importante é que tanto o sistema de controle interno como 
o de risco são grandes aliados na implantação da Governança de TI na 
organização. 




O Modelo de Governança de TI 


Um ponto importante da ideia de apresentar um modelo genérico de Go¬ 
vernança de TI é que ele pode ser adaptado para qualquer tipo de organização, 
sendo que seus componentes podem ser encarados como peças de um “lego”, 
que vão sendo construídas e implantadas de acordo com as prioridades, ne¬ 
cessidades e disponibilidades da organização. 

Entretanto, nunca podemos esquecer que um dos maiores desafios que 
uma área de TI tem é o de promover o seu alinhamento com o negócio, o 
que exige grandes doses de negociação e educação dos dirigentes das áreas de 
negócio e, obviamente, grande capacidade do CIO para fazê-lo acontecer. 

Poderíamos até usar alguns slogans para essa nova era de flexibilidade para 
o negócio: 

□ TI não é mais assunto somente da TI. 

□ O CIO deve liderar a mudança. 

□ TI deve ser flexível para lidar com as mudanças do negócio. 

□ Prioridades de TI devem ser prioridades do negócio e não de pessoas, 
para isso mecanismos de gestão de portfólio devem ser corporativos. 

□ Os itens que representam elementos de custeio de TI devem ser cons¬ 
tantemente reavaliados quanto à sua permanência ou não. 

□ Os resultados de investimentos em TI devem ser medidos pela cria¬ 
ção de valor ao negócio e pela diminuição da exposição do negócio a 
riscos operacionais. 

□ Implantar governança de TI depende de marketing interno. 

□ Implantar governança de TI implica em mudanças de cultura, de to¬ 
dos da organização. 

□ Por fim, a TI deve ser gerenciada como um negócio. 
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3.1 Visão geral do modelo de Governança de TI 

O modelo genérico sugerido baseia-se em um fluxo de máo dupla que se¬ 
gue o “Ciclo da Governança de TI” 4 . A visão geral deste modelo é apresentada 
na Figura 3.1. 

Este modelo apresenta funções típicas de Governança de TI e um fluxo, 
que segue desde o alinhamento até a comunicação do resultado da TI. 

Os componentes típicos da Governança de TI são: 

□ Riscos e compliance : consiste na definição da tolerância de riscos 
da organização e na avaliação conjunta dos riscos com o negócio, 
assim como na garantia de que a TI está aderente com requisitos 
de compliance externos e internos (através dos controles internos 
aplicáveis). 

□ Avaliação independente: consiste na promoção de avaliações (au¬ 
ditorias) independentes para verificar a conformidade da TI com re¬ 
quisitos de compliance externos e com os controles internos aos quais 
está submetida. 

□ Gestão da mudança organizacional: consiste no processo de ava¬ 
liar a prontidão para a mudança das áreas de TI, em função da im¬ 
plantação de inovações em processos de gestão e operacional, do 
planejamento da mudança, do estabelecimento de mecanismos de 
recompensas para a mudança e do gerenciamento da implantação 
da mudança. 

□ Alinhamento estratégico: consiste na interação entre a TI e a alta 
administração no sentido de estabelecer os mecanismos de direitos 
decisórios, assim como a obtenção dos direcionadores estratégicos e 
objetivos de negócio que irão afetar a TI, bem como a sua contribui¬ 
ção para a operação e objetivos do negócio. 

□ Entrega de valor: consiste no gerenciamento dos programas e proje¬ 
tos, na avaliação do valor entregue e no gerenciamento disciplinado 
do portfólio de TI. 


4 Já discutido no Capítulo 1. 
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□ Gestão do desempenho: consiste na definição de indicadores, me¬ 
canismos de coleta e análise de indicadores de resultado (metas) e de 
desempenho da TI. 

□ Comunicação: consiste na comunicação do valor entregue pela TI ao 
negócio e em relação ao seu desempenho no atendimento dos níveis 
de serviços e das metas estabelecidas pelo planejamento estratégico. 

□ Gerenciamento de recursos: consiste na supervisão do investimento, 
do uso e da alocação dos recursos de TI por meio de avaliações perió¬ 
dicas das iniciativas e operações de TI, visando assegurar a existência 
de recursos suficientes e o alinhamento com objetivos estratégicos e 
necessidades de negócios atuais e futuras. 

Os componentes de gestão e operacionais são: 

□ Estratégia do negócio: consiste nos direcionamentos estratégicos do 
negócio, objetivos, planos funcionais de outras áreas da organização, 
mapa estratégico da organização, além do plano estratégico de médio 
e longo prazos, que devem ser considerados por TI para o desenvol¬ 
vimento de sua estratégia de serviços. 

□ Estratégia de TI: consiste na elaboração do plano de TI, que pode 
ter uma visão externa, para os projetos, serviços e inovações para o 
negócio e uma visão interna, composta dos projetos e inovações que 
a TI deve implantar para poder atender aos seus clientes e usuários 
na organização. Este plano pode conter o Mapa Estratégico e o BSC 
da TI. 

□ Plano de TI - negócios: consiste em projetos, serviços e inovações da 
TI para o negócio, como implantação de novas aplicações, manuten¬ 
ções de aplicações, implantação de sistemas integrados de gestão, de 
serviços de TI e de projetos de infraestrutura para apoiar os processos 
de negócio da organização. 

□ Plano de TI - internos: consiste nos projetos e inovações que a 
TI tem que implantar para atender ao Plano de TI - negócios, tais 
como a implantação de processos operacionais e gerenciais, desen¬ 
volvimento de recursos humanos, capacitação de pessoal, estratégia 
de sourcing , segurança da informação, arquitetura da informação, 
arquitetura tecnológica, organização, estabelecimento de objetivos 
de desempenho etc. 
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□ Mecanismos de decisão: consiste no estabelecimento e no apoio a 
comitês requeridos para tomada de decisões sobre a TI (que são os me¬ 
canismos de direitos decisórios), os critérios de priorização e a priori- 
zação dos investimentos em TI, visando estabelecer o portfólio de TI. 

□ Portfólio de TI (orçamento e investimentos): consiste no estabe¬ 
lecimento do Portfólio de TI aprovado a partir da priorização e nos 
mecanismos de seu gerenciamento. 

□ Clientes/usuários: consiste nos processos de relacionamento da TI 
com os seus clientes e usuários. 

□ Operações de serviços: consiste no gerenciamento e na execução dos 
projetos, serviços e inovações de TI para o negócio e para a própria TI. 

□ Fornecedores: consiste no gerenciamento de contratos e serviços for¬ 
necidos por terceiros. 

□ Resultados da TI: consiste nos indicadores de desempenho e de resul¬ 
tados da TI em função da execução de projetos, serviços e inovações. 

□ Resultados para o negócio: consiste nos resultados da TI para o ne¬ 
gócio, em termos de apoio ao aumento da rentabilidade, à redução de 
custo, ao lançamento de novos produtos, ao aumento de participação 
no mercado, à expansão física do negócio etc. 

□ Comunicação e reporte de resultados: consiste na comunicação às 
partes interessadas (geralmente os executivos de negócio e alta admi¬ 
nistração) sobre o desempenho da TI e no atendimento aos níveis de 
serviços acordados e objetivos do negócio. 

A estruturação de funções e responsabilidades sobre a Governança de TI na 
organização é o ponto inicial de partida. A forma como vai ser realizada de¬ 
pende de organização para organização. Geralmente é estabelecida uma área 
ou grupo de pessoas com a responsbilidade pela implantação da Governança 
de TI. 

O alinhamento estratégico é o ponto de partida para a área de TI criar va¬ 
lor para o negócio e garantir a aderência a requisitos de compliance. 

O primeiro evento de alinhamento é o que chamamos de “alinhamento 
estático”, pois deriva de algum momento em que a empresa planeja o seu 
futuro. A partir dos objetivos e das estratégias do negócio (de curto, médio e 
longo prazos), derivam-se iniciativas estratégicas de TI, que são transformadas 
em projetos e serviços e, possivelmente, o Plano de Tecnologia da Informação, 
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que, no nosso entender, está no mesmo nível de outros planos funcionais da 
organização (que também são derivados de objetivos estratégicos dos Planos 
de Marketing , Vendas, Produção, Logística etc.). 

Os princípios de TI, se já existirem, podem orientar as escolhas estratégicas 
contidas no Plano de Tecnologia da Informação. Caso não existam, defini-los 
será certamente outra tarefa do alinhamento. 

A partir do alinhamento estratégico (estático neste momento), o passo se¬ 
guinte é definir as prioridades de TI (sejam elas soluções estratégicas, projetos 
de aplicativos ou soluções, projetos de manutenção de ativos ou projetos de 
processo, organização e serviços), gerando um portfólio de TI. 

A definição sobre o que manter e sobre em que investir vai depender dos 
mecanismos de decisão corporativos criados para tal, como, por exemplo, um 
Comitê de Projetos com a participação dos usuários e executivos. 

O portfólio vai orientar as ações do dia a dia e ser alimentado por elas. Esse 
instrumento vai unir as estratégias de curto, médio e longo prazos à rotina 
diária das operações de serviços de TI. 

Pode haver mudanças no negócio? Com certeza, sim (aliás, 100% de certe¬ 
za!). Portanto, mudanças no negócio que acarretem mudanças em demandas 
para a TI devem recompor o portfólio e, por conseguinte, o Plano de Tecno¬ 
logia da Informação. É o que chamamos de “alinhamento dinâmico” da TI. 
Em outras palavras, os objetivos e as estratégias de negócio devem ser sempre 
revisitados, mesmo que não estejam claros para o pessoal do negócio. 

O portfólio de TI deve direcionar o relacionamento com os clientes (in¬ 
ternos e externos), assim como com os fornecedores e parceiros de TI. Teo¬ 
ricamente, não deveria ser permitido o atendimento de demandas que não 
estejam enquadradas no portfólio. Mudanças deveriam ser negociadas e, se 
forem importantes e requeridas pelo negócio, deveriam ser entendidas como 
mudanças ou refinamentos nos objetivos e estratégias do negócio. 

O relacionamento com os clientes e o relacionamento com os fornecedores 
são subconjuntos do portfólio que guiam o dia a dia das operações de serviços 
de TI. 

As operações de serviços de TI proporcionam os serviços requeridos pelos 
clientes internos (dentro da organização, a própria área de TI) e externos à 
organização (clientes propriamente ditos e, às vezes, os fornecedores). Esse 
aspecto pode ser entendido como a entrega de valor da TI. 

No modelo, a organização e os instrumentos das diversas operações devem 
ser derivados do alinhamento estratégico. Os projetos internos de TI, como, 
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por exemplo, a implantação de uma metodologia de desenvolvimento de sis¬ 
temas, devem estar previstos no portfólio de TI. 

Objetivos de desempenho e níveis de serviço podem ser estabelecidos desde o 
Plano de Tecnologia da Informação e devem ser medidos em intervalos de tempo 
preestabelecidos. As medições são realizadas no nível de cada operação de serviço. 

A gestão do desempenho de TI é derivada dessas medições, as quais po¬ 
dem ser consolidadas mediante tratamento específico (fórmulas) para gerar 
indicadores de desempenho e de resultado, que, por sua vez, vão mostrar se 
as decisões estratégicas e táticas tiveram efeito real no desempenho esperado 
para as operações, apontando quais ações são necessárias para aumentar o 
desempenho ao longo do tempo. 

Ainda no modelo, temos as medições de resultados dos projetos, serviços 
e inovações para o negócio, que são o que realmente interessa para o negócio. 
Por exemplo: a TI atende aos picos de operação do negócio com alta dispo¬ 
nibilidade, integridade e confiabilidade? Ou: o projeto de negócio, apoiado 
por TI, conseguiu gerar a receita necessária? Ou ainda: o projeto de inovação 
proposto por TI reduziu o custo do negócio? 

A comunicação é crítica para todo o processo, pois é o meio pelo qual a TI 
informa o seu desempenho de forma transparente para o negócio (executivos 
e alta administração) e através do qual a TI demonstra o seu valor para o 
negócio. Quanto mais a TI demonstrar valor, maiores serão as possibilidades 
do negócio investir em mais inovações, projetos e serviços de TI e obter os 
benefícios com o uso da tecnologia da informação. 

Entretanto, nada garante que os princípios e mecanismos da Governança 
de TI sejam implantados, mantidos e evoluídos sem um gerenciamento de 
mudança organizacional. Nossa experiência tem demonstrado que este é um 
ponto crítico na implantação da Governança de TI, pois quando ocorrem 
mudanças na organização há ganhadores e perdedores. Às vezes, esses perde¬ 
dores opõem forte resistência à mudança e, muitas vezes, são pessoas-chave 
para a organização. Muitas vezes eles vencem! 

Por fim, temos que garantir que o que foi implantado seja seguido, contro¬ 
lado, monitorado, atendendo aos parâmetros de riscos da TI para o negócio, 
aos requisitos de compliance externos (leis, regulações, etc.) e aos controles 
internos requeridos para a TI. 

Após esta breve descrição do modelo de Governança de TI, vamos a um 
detalhamento maior de seus componentes. 
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3.2 O ALINHAMENTO ESTRATÉGICO DE TI 

3.2.1 O QUE É O ALINHAMENTO ESTRATÉGICO 

O alinhamento estratégico pode ser realizado com ou sem um plano estra¬ 
tégico de negócios formal. 

Não adianta a empresa ter somente um conjunto de metas de vendas ou de lu¬ 
cratividade sem ter o detalhe sobre como atingir as metas e a lucratividade preten¬ 
dida. Para quem se encontra numa situação dessas, é fundamental tentar entender 
os movimentos competitivos que a diretoria da empresa faz, assim como entender 
profundamente o negócio, em termos dos fatores críticos de sucesso. 

Como a literatura tem definido, “alinhamento estratégico” é o processo de 
transformar a estratégia do negócio em estratégias e ações de TI que garantam 
que os objetivos de negócio sejam apoiados. 

O mercado de cada empresa define a estrutura do negócio e é o campo de 
batalha competitivo. Neste sentido, cria elementos competitivos que têm im¬ 
pacto na forma como a empresa vislumbra novas oportunidades de negócio, 
desenvolve produtos e serviços, realiza as suas vendas e aquisições de insumos 
e recursos, transforma-os em produtos e serviços, usa a tecnologia de produtos 
e assim sucessivamente. 

O mercado também fornece informações sobre ameaças ao negócio repre¬ 
sentadas pela barganha de fornecedores e compradores, pelo aparecimento 
de produtos e serviços substitutos, pelo surgimento de novas tecnologias de 
processo e de produto patenteadas que possam mudar a forma de vender e 
distribuir, pela forma de gerir a cadeia de suprimentos etc. 

Geralmente, o que se observa é a definição de um conjunto de estratégias 
considerando um cenário de produto/serviço e mercado presente e futuro, 
ou a partir de um novo posicionamento competitivo com a mudança dos 
elementos da oferta de valor da empresa para o mercado 5 . Isso significa que as 
linhas de produtos e serviços da empresa podem requerer o emprego simultâ¬ 
neo de várias estratégias, o que torna a questão do alinhamento e da própria 
operação de TI bem mais complexa. 

Atualmente, o alinhamento estratégico é bidirecional, ou seja, da estratégia 
do negócio para a estratégia de TI e vice-versa, pois a TI pode potencializar 
estratégias de negócio que seriam impossíveis de ser implantadas sem o auxílio 
da tecnologia da informação. 


5 Vide o trabalho de Kim & Mauborgne (2005). 
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A Figura 3.2 mostra o esquema de alinhamento estratégico proposto por 
Henderson & Venkatraman (1993), onde a estratégia de TI influencia e é in¬ 
fluenciada pela estratégia de negócio e interage bidirecionalmente com a infraes- 
trutura e os processos de TI e com a infraestrutura e os processos organizacionais. 

Várias estratégias simultâneas podem requerer processos de negócio distin¬ 
tos, tanto do ponto de vista operacional como da gestão. Para a TI, isto signi¬ 
fica um forte impacto quando se define a Arquitetura de TI, visando obter o 
máximo de compartilhamento de recursos. 

Vide o caso dos bancos de varejo no Brasil, que atendem tanto clientes de 
baixo poder aquisitivo como de classe média e classe média alta. 

Para os clientes de classe média alta, esses bancos criaram estruturas, sistemas, 
atendimento, marketing e processos operacionais diferenciados. Isto requer para 
a TI a especialização de alguns aplicativos, além de dados mais detalhados sobre 
as transações dos clientes. Na realidade, para esse público, a agência virtual ou 
física torna-se uma verdadeira banca de vendas de serviços e produtos bancários. 


ESTRATÉGIA DE NEGÓCIO ESTRATÉGIA DE TI 



INFRAESTRUTURA E PROCESSOS INFRAESTRUTURA E 

ORGANIZACIONAIS PROCESSOS DE TI 

Integração Funcional 


Figura 3.2 - Modelo de alinhamento estratégico 

Fonte: Henderson & Venkatraman (1993) 
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Esta visão da estratégia de negócio versus a estratégia de TI é fundamental 
para o alinhamento estratégico. 

O alinhamento estratégico ocorre em vários momentos na vida da em¬ 
presa. Um momento acontece quando o board da organização se reúne para 
definir objetivos de negócio de médio e longo prazos e estabelece estratégias 
para atingir esses objetivos. Geralmente é produzido um plano estratégico, 
plano de negócios ou algo equivalente. A partir desse ponto, objetivos e es¬ 
tratégias funcionais são desdobrados e sincronizados para marketing e vendas, 
operações, logística, recursos humanos, tecnologia da informação, pesquisa e 
desenvolvimento etc. 

Outros momentos acontecem quando este mesmo board redefine aleato¬ 
riamente o seu plano de negócios em função de novas oportunidades ou ce¬ 
nários macroeconômicos e microeconômicos de negócios. 

Por fim, esse alinhamento ocorre no dia a dia, quando os clientes de TI 
demandam soluções novas que mudam os requisitos do negócio estabelecidos 
no alinhamento estático, quando foi feito o plano de tecnologia. Neste caso, 
a TI tem que ser bastante flexível. 

Chamamos de alinhamento estático a derivação da estratégia de TI a partir 
do Plano Estratégico ou de Negócios da empresa e de alinhamento dinâmico 
a alteração da estratégia de TI em função da mudança aleatória da estratégia 
de negócios da empresa. 

Para ser efetivo e robusto, um modelo de Governança de TI tem que con¬ 
templar esses dois alinhamentos. 

A Figura 3.3 mostra que, inicialmente, o Plano de Tecnologia é produto do 
alinhamento estático face às estratégias de negócio “intencionadas”, ou seja, as 
estratégias documentadas ou comunicadas logo após um processo (formal ou 
informal) de planejamento estratégico. 

Durante a implantação das estratégias de negócio “intencionadas”, ocor¬ 
rem mudanças no cenário do mercado, da economia ou da política, fazendo 
com que as estratégias inicialmente traçadas sofram alterações. Temos então, 
neste momento, as estratégias que estão sendo, de fato, executadas (ou seja, 
“realizadas”). Essas estratégias irão requerer novo alinhamento da TI, a que 
chamamos de alinhamento dinâmico. 

Lembramos, porém, que, mesmo que a empresa não tenha claro o seu 
“plano de negócios”, é possível realizar o alinhamento estratégico estático, o 
que vai subsidiar o seu Plano de Tecnologia da Informação. 
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Figura 3.3 - Alinhamento estratégico e comportamento da estratégia de negócio 


Há diversas formas de fazer a análise estratégica do negócio para TI. Algu¬ 
mas delas sáo: 

□ Identificação, através do plano estratégico do negócio ou através da 
observação das ações da empresa, das estratégias empresariais que a 
empresa adota e daquelas que seráo adotadas para atingir objetivos 
traçados. 

□ Identificação dos fatores críticos de sucesso da empresa. 

□ Análise de planos táticos funcionais. 

□ Balanced Scorecard de TI 6 . 

Essas análises podem ser cotejadas com o portfólio atual de TI visando 
determinar os gaps que deveráo ser preenchidos. 

A seguir, apresentamos um detalhamento do Plano de Tecnologia da In¬ 
formação. A abordagem apresentada aqui é aplicável em organizações que 
necessitam rever o alinhamento da TI ao negócio, ou que necessitam rever de 


6 Vide a discussão desta técnica no Capítulo 12. 
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forma mais profunda o alinhamento da infraestrutura de aplicações e tecnoló¬ 
gica e das demais políticas e processos de TI, em apoio aos serviços fornecidos 
aos usuários e clientes. 

Entretanto, se a sua organização já está madura em termos de TI, tem uma 
infraestrutura de aplicações e tecnológica mais ou menos estabilizada, com 
poucas mudanças transformadoras, pode usar uma abordagem mais estraté¬ 
gica, através da elaboração do Mapa Estratégico e do BSC de TI, que será 
discutido mais adiante, no item 3.2.3. 


3.2.2 O Plano de Tecnologia da Informação 

O Plano de Tecnologia da Informação é o principal produto da fase de ali¬ 
nhamento estratégico, conforme o modelo de Governança de TI proposto. Ele 
é derivado do “momento” de alinhamento estratégico da organização e atua¬ 
lizado sempre quando há mudanças na estratégia. Num primeiro instante, o 
alinhamento estratégico ocorre quando se está construindo ou elaborando o 
plano estratégico empresarial (que pode ser formal ou informal). 

Geralmente, é feito para períodos náo superiores a três anos, com maior 
detalhe no primeiro ano e com revisões anuais. 

A elaboração do Plano de Tecnologia comumente segue um processo que 
se inicia após ou durante a definição dos objetivos e estratégias da companhia, 
ou seja, durante o alinhamento estratégico. 

Nesse processo, a TI deve participar da definição dos objetivos e das estra¬ 
tégias da empresa, sugerindo novas oportunidades de negócio com o uso da 
tecnologia da informação ou apoiando os demais objetivos e estratégias fun¬ 
cionais, de marketings vendas, manufatura, logística, recursos humanos etc. 

Dependendo da postura de TI, a elaboração do plano pode ser feita a partir 
dos objetivos e estratégias definidos. 

Eventualmente, as “áreas de controle interno” das empresas podem exigir 
da área de TI a elaboração de um plano. Essa é a postura menos recomendada 
para TI. O plano não pode servir apenas para eliminar pontos de auditoria 
ou para atender a requisitos de compliance, mas ser um elemento de apoio à 
gestão do CIO e dos demais gerentes de TI e da própria empresa, além de ser 
um elemento de comunicação entre TI e negócio. 

A Figura 3.4 mostra uma visão macro de um processo de planejamento 
estratégico empresarial típico. 
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Figura 3.4 - Processo de planejamento estratégico empresarial 


O Plano de TI pode ser visto como um dos planos funcionais, cujos pro¬ 
jetos e serviços sáo derivados e estão em linha com a estratégia empresarial e 
competitiva e os demais planos funcionais da organização. 

Para melhor entendimento: 

□ Inteligência competitiva : refere-se ao tratamento de informações inter¬ 
nas e externas acerca de mercado, clientes, concorrentes, fornecedores, 
de cunho político, legal, social e econômico, assim como à avaliação 
de oportunidades, pontos fracos e pontos fortes, que servem de base 
para a revisão ou elaboração da estratégia corporativa e competitiva. 

□ Estratégia corporativa : procura responder a questões tais como: em que 
negócio atuar, diversificar ou focalizar, como alocar recursos a diferen¬ 
tes negócios, que novo negócio ou mercado deve ser desenvolvido etc. 

□ Estratégia competitiva e de posicionamento : procura responder sobre 
a missão da empresa, quais os objetivos estratégicos do negócio, qual 
a estratégia competitiva (liderança em custo, diferenciação, enfoque), 
qual a estratégia de crescimento do negócio ou mesmo qual a estraté¬ 
gia de um novo posicionamento estratégico. 
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□ Plano estratégico: documenta as intenções da administração sobre 
como atingir os objetivos estratégicos do negócio. Estabelece as ações 
necessárias para que os objetivos do negócio sejam atingidos. 

□ Planos funcionais: desdobram as estratégias em projetos e ser¬ 
viços que devem ser desenvolvidos para que os objetivos sejam 
atingidos. 

A Figura 3.5, a seguir, mostra um modelo de relacionamento básico entre 
os principais planos funcionais de uma organização. 

O Plano de Tecnologia da Informação deve apoiar toda a operaçáo, em 
termos de desenvolvimento de novas soluções para as necessidades do negó¬ 
cio, da manutenção das soluções, dos aplicativos e dos demais ativos de TI, 
da implantação e manutenção de soluções de serviços associados ao uso dos 
ativos e da infraestrutura. Neste sentido, também é apoiado por outros planos 
como o de recursos humanos e de funding. 



Figura 3.5 - Relacionamento entre planos funcionais 
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Lembramos, todavia, que os “princípios de TI” orientam as resoluções 
do Plano de TI. Se tais princípios não existirem ou não estiverem claros 
dentro da empresa, a hora de abordá-los é durante a elaboração do plano 
de TL 

O processo de alinhamento estratégico revelará requisitos do negócio 
para TI, os quais vão alimentar o estudo da demanda por serviços, recur¬ 
sos e infaestrutura, sendo transformados em objetivos de desempenho e 
acordos de níveis de serviço para clientes externos e internos, em neces¬ 
sidades de novas soluções, de infraestrutura de TI e de outros recursos e 
serviços de TL 

O entendimento da dinâmica do negócio auxilia na determinação do vo¬ 
lume e do tipo de serviços que são (ou serão) requeridos da TI, o que pode 
direcionar a determinação dos níveis de serviços que devem ser negociados 
com os usuários/clientes. 

As necessidades de soluções são avaliadas em face do atual portfólio de TI e 
da atual arquitetura de TI da empresa. Se não houver um “desenho”, o enten¬ 
dimento e o estabelecimento do padrão da arquitetura de TI, a oportunidade 
para fazê-lo é durante a elaboração do plano de TL 

As necessidades de aplicações poderão ajudar no “desenho” da arquitetura 
de TI, se ela ainda não existir, e na definição da infraestrutura de serviços de 
TI, que dará suporte para que as necessidades de aplicações, dentro de uma 
arquitetura de TI, tornem-se realidade. 

Todos os requisitos anteriores vão exigir uma capacidade adequada de re¬ 
cursos, sejam computacionais, materiais e humanos, que também deve ser 
planejada. 

Outro aspecto importante no Plano de Tecnologia é decidir sobre qual 
será a estratégia de sourcing. Mais precisamente, qual o tipo (ou quais os 
tipos) de sourcing a empresa quer, ou seja, relativo ao desenvolvimento de 
sistemas, à infraestrutura de serviços de TI, suporte a usuários, um full out- 
sourcing etc. 

Uma vez definidas as necessidades futuras em termos de soluções de apli¬ 
cações, arquitetura e infraestrutura de TI, capacidade e sourcing , deve-se rea¬ 
valiar a organização das operações de serviços de TI, considerando processos 
operacionais, de gestão, de relacionamento com os clientes e com os fornece¬ 
dores, assim como as competências necessárias. 
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Em função do tipo de negócio da empresa e dos tipos de arquitetura e 
infraestrutura de TI requeridos, é possível identificar os requisitos da infraes- 
trutura de segurança da informação. 

O conjunto de necessidades, recursos e competências requeridos deve ser 
avaliado, então, quanto aos aspectos de segurança da informação e gestão de 
riscos. 

Por fim, as necessidades derivadas do Plano Estratégico formarão o 
Novo Portfólio de TI e deverão ser priorizadas de acordo com critérios 
específicos. 

O plano somente estará completo quando as prioridades de investimen¬ 
tos e manutenção de itens de custeio estiverem decididas, formando o que 
chamamos de Portfólio Aprovado, ou seja, aquele que deverá ser executado e 
que guiará o dia a dia da organização de TI. Logo após o estabelecimento do 
orçamento de capital e de custeio, os níveis de serviço requeridos devem ser 
revistos para refletirem as formulações do plano. 

O Plano de TI pode ser subdividido em duas peças, uma delas voltada para 
as necessidades do negócio, em termos de aplicações de apoio aos processos 
gerenciais e operacionais (por exemplo: manutenção de aplicações existentes, 
upgrade em sistemas de gestão integrados, desenvolvimento de soluções de 
Business Intelligence, implantação de sistemas de relacionamento com clientes, 
automação de chão de fábrica etc.). 

A outra pode ser orientada especificamente para a capacitação da TI em 
atender aos serviços, projetos e inovações que serão implantadas no negó¬ 
cio (por exemplo: projetos de processos de TI, tais como implantação de 
segurança da informação, metodologia de gestão de projetos, processo de 
gerenciamento de outsourcing , processo de gestão de mudanças, inovações 
tecnológicas que devem ser estudadas, mudanças organizacionais em TI, 
programas de capacitação de pessoas, projeto de novos serviços, melhoria da 
arquitetura da TI, arquitetura de software etc.). 

O resultado da combinação dessas duas peças é o Portfólio de TI aprovado, 
que deverá ser executado uma vez que as prioridades sejam establecidas pelos 
comitês específicos para tal. 

A Figura 3.6 mostra os passos para a elaboração do Plano de Tecnologia da 
Informação. 
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Figura 3.6 - Processo de elaboração do Plano de Tecnologia da Informação 


A seguir apresentamos um detalhamento de cada etapa da elaboração do 
Plano de Tecnologia da Informação. 


3.2.2.1 Análise estratégica da organização 

A análise estratégica da organização tem por objetivo o entendimento 
dos requisitos do negócio que impactam TI e compreende os seguintes 
pontos: 

□ Entendimento da estrutura do negócio. 

□ Entendimento dos objetivos estratégicos do negócio, visando o des¬ 
dobramento desses objetivos para TI. 
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□ Entendimento dos fatores críticos de sucesso do negócio. 

□ Identificação dos requisitos para TL 

3.2.2.1.1 Entendimento da estrutura do negócio 

De acordo com Porter (1989), a estrutura de um negócio pode ser enten¬ 
dida conforme o modelo apresentado pela Figura 3.7 a seguir: 
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Figura 3.7 - Modelo de forças competitivas de Porter 
Fonte: Porter (1989) 


De acordo com o modelo, uma organização com fins lucrativos sofre bar¬ 
ganha de fornecedores e compradores, é ameaçada por novos entrantes no 
mercado, pela concorrência e por produtos substitutos. 7 

O entendimento sobre como a organização se situa neste espaço competi¬ 
tivo a direciona para definir direcionadores estratégicos como: 


7 No Capítulo 16, exploraremos o alinhamento estratégico em organizações públicas. 
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□ Se o segmento do produto/serviço sofre grande barganha dos for¬ 
necedores e compradores e as margens sáo reduzidas, então ela deve 
concorrer com base na estratégia de Liderança em Custo. 

□ Se o segmento do produto/serviço é muito inovador e dinâmico, com 
produtos substitutos e novos entrantes no mercado, é provável que a 
empresa vai querer se diferenciar. Portanto, ela deve adotar a estraté¬ 
gia de Liderança por Diferenciação. 

□ Se o segmento do produto/serviço é um nicho de mercado, ela deve 
adotar a estratégia de Enfoque. 

Todo tipo de indústria, seja bancária, telecom, comércio, serviço, agribusi- 
ness etc., tem sua estrutura mais ou menos similar e que gera fatores críticos 
de sucesso mais ou menos parecidos, por exemplo: 

□ No segmento de banco de varejo, o fator crítico de sucesso é atendi¬ 
mento de massa e extensivo no território nacional, com grande gama 
de produtos e serviços e com alto grau de disponibilidade, confiabili¬ 
dade e integridade. Neste caso, os custos são a tônica, pois, à medida 
que os produtos e serviços são disponibilizados pela internet, auto- 
atendimento e por centrais telefônicas de relacionamento, os custos 
de transações caem drasticamente, assim como os investimentos em 
infraestrutura de agências. No caso de grandes redes varejistas no co¬ 
mércio, existe forte concorrência e as margens são muito apertadas, 
mesmo que haja uma forte barganha junto a fornecedores por redução 
de custo. 

□ Na indústria de telecom, pela sua dinâmica, serviços maduros são 
pressionados por custo e por produtos substitutos (tais como Skype 
e MSN, no caso de telefonia fixa e até mesmo celular). Visando au¬ 
mentar receitas e lucratividade, investem fortemente em conteúdo e 
convergência de mídias. Neste caso, há duas estratégias, liderança em 
custo e diferenciação. 

A Tabela 3.1 a seguir apresenta alguns requisitos para TI, em função do 
tipo da estratégia empresarial derivada da estrutura do negócio na qual a em¬ 
presa está inserida. 
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Estratégia empresarial 

Requisitos de Negócio para TI 

Enfoque 8 

A TI deve apoiar a flexibilização dos processos relacionados 
a clientes, engenharia de produto, gestão do conhecimento 
(proprietário), relacionamento com fornecedores e integração dos 
processos de negócio. 

Diferenciação 

A TI deve apoiar a implantação de processos de engenharia, 
desenvolvimento e operação de serviços e produtos únicos, 
diferenciados, assim como processos robustos de relacionamento 
com clientes e uso de informações para desenvolvimento de novos 
produtos. A empresa necessita também ter uma plataforma flexível 
de produção para mudar rapidamente. 

0 foco em novas tecnologias da TI é sobre aquelas que vão criar 
novas oportunidades de negócio para a empresa. 

Custo 

A TI deve garantir a integração de processos de negócio (desde 
o pedido até a entrega do produto e serviço) com o mínimo 
desperdício possível. 0 foco em novas soluções da TI é sobre 
aquelas que vão reduzir custos para a empresa. 


Tabela 3.1 - Estratégias empresariais e requisitos de TI 


A partir desse entendimento, alguns fatores críticos de sucesso para TI já 
começam a ser entendidos. 


3.2.2.1.2 Entendimento dos objetivos estratégicos do negócio 

A presente abordagem pode ser usada tanto para casos onde não há um 
plano estratégico formal, onde as ações de negócio devem ser interpretadas 
em estratégias empresariais, como para aqueles casos onde existe um plano 
estratégico. Mesmo assim, devemos interpretar os objetivos de negócio em 
tipos de estratégias. 

E importante salientar que esse exercício de interpretação deve ser feito 
para cada célula de produto-segmento, ou seja, a interpretação deve ser reali¬ 
zada para cada segmento de mercado em que a empresa atua, com produtos 
específicos ou derivados de plataformas de produto. 

A Tabela 3.2 a seguir exemplifica a relaçáo “açáo empresarial - estratégia - 
requisitos de negócio para TI”. É uma forma de descobrir qual o impacto da 
estratégia competitiva e de negócios da empresa sobre a TI. 


8 Vide o trabalho de Porter (1999) sobre estratégias competitivas. 
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Ação empresarial 
percebida 

Estratégia 

empresarial 

Requisitos de Negócio para TI 

Criar produtos e serviços para 
nichos de mercado 

Enfoque 

A TI deve apoiar a flexibilização dos processos 
relacionados a clientes, engenharia de produto, gestão 
do conhecimento (proprietário), relacionamento com 
fornecedores e integração dos processos de negócio. 

Criar produtos e serviços 
diferenciados usando a mesma 
plataforma 

Diferenciação 

A TI deve apoiar a implantação de processos de 
engenharia, desenvolvimento e operação de serviços e 
produtos únicos, diferenciados, assim como processos 
robustos de relacionamento com clientes e uso de 
informações para desenvolvimento de novos produtos. 

A empresa necessita também ter uma plataforma 
flexível de produção para mudar rapidamente. 

0 foco em novas tecnologias da TI é sobre aquelas que 
vão criar novas oportunidades de negócio para a empresa. 

Ter o produto e serviço de 
menor custo 

Custo 

A TI deve garantir a integração de processos de 
negócio (desde o pedido até a entrega do produto e 
serviço) com o mínimo desperdício possível. 0 foco em 
novas soluções da TI é sobre aquelas que vão reduzir 
custos para a empresa. 

Busca de maior participação 
dos produtos e serviços atuais 
nos mercados atuais 

Penetração de 
mercado 9 

A TI deve apoiar otimizações de processos para 
redução de custos, assim como garantir um 
desempenho superior aos fatores chaves de 
competição no mercado atual e que sejam ganhadores 
de pedido. Esses fatores podem estar no preço e na 
qualidade (do produto, do atendimento, da entrega, 
conforme o pedido). 

Introdução de produtos e 
serviços atuais em novos 
mercados 

Desenvolvimento 
de mercado 

A TI deve apoiar fortemente os processos de 
planejamento de mercado, vendas e logística, visando 
garantir o fluxo permanente de entrega dos produtos e 
serviços para os novos mercados. 

Desenvolvimento de novos 
produtos e serviços para 
mercados atuais 

Desenvolvimento 
de produto 

A TI deve apoiar pesquisa e desenvolvimento, engenharia 
de produto, gestão do desenvolvimento de produtos, 
marketing e processos de inteligência competitiva. 

Desenvolvimento de novos 
produtos e serviços para novos 
mercados 

Diversificação 

A TI deve apoiar pesquisa e desenvolvimento, 
engenharia de produto, gestão do desenvolvimento de 
produtos, marketing, manufatura, distribuição e vendas. 

Associação, joint venture ou 
aquisições fora do ramo de 
negócio 

Crescimento 

conglomerativo 

A TI pode integrar serviços e arquiteturas e 
compartilhá-las. 


9 Vide Kotler (2002) para informações acerca de estratégias empresariais. 
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Ação empresarial 
percebida 

Estratégia 

empresarial 

Requisitos de Negócio para TI 

Criar barreiras de entrada para 
novos entrantes no mercado 

Manutenção de 
posição/território 

A TI pode apoiar processos e produtos que reduzam os 
custos do cliente ou que aumentem o seu desempenho, 
visando criar barreiras contra as vantagens 
competitivas de novos entrantes. 

Criar novos mercados 
(inexistentes) 

Estratégia do blue 
ocean' 0 

A TI pode auxiliar na prospecção de novas tecnologias 
e soluções que possam criar um novo mercado ainda 
inexplorado. 


Tabela 3.2 - Estratégias empresariais e requisitos de TI 


Entretanto, deve-se ter cuidado ao analisar as estratégias da empresa, pois po¬ 
dem estar equivocadas em função das características da estrutura do ramo de ne¬ 
gócio em que atua. O que queremos dizer com isso é que nem sempre a alta dire¬ 
ção tem razão, ou seja, ela pode estar equivocada ao decidir sobre uma estratégia, 
pois a decisão pode ser tomada sem a devida análise do contexto competitivo. 

Por exemplo, suponha que a estrutura do seu negócio requeira uma estra¬ 
tégia baseada em liderança no custo, pois o seu produto compete com base 
no preço (é uma commodity ). Qualquer ação de diferenciação do produto não 
vai fazê-lo vender mais. 

Se a empresa possui um Plano Estratégico, é provável que existam planos 
funcionais ou objetivos estratégicos formais que são desdobrados pela organi¬ 
zação. Este é o melhor dos mundos, pois não há necessidade de interpretação 
sobre a estratégia de negócio da empresa. * 11 

Os planos funcionais (pelo menos esperamos isto) são derivados dos des¬ 
dobramentos das estratégias estabelecidas para o negócio. Tais planos refletem 
as estratégias em programas, projetos, serviços e ações e constituem-se em 
ótimas fontes de informação para que seja possível identificar necessidades de 
aplicações de TI, em apoio à estratégia do negócio. 

Por exemplo, um plano funcional de marketing tem informações sobre os 
programas de marketing para produtos atuais ou novos produtos, programas 
de inteligência de mercado, programas de marketing institucional etc. 


10 Vide o trabalho de Kim e Mauborgne (2005). 

11 Pode parecer incrível, mas muitas empresas não têm uma estratégia clara e definida e comunicada 
por toda a organização. Uma estratégia somente é válida se todos, na organização, a entendem e a 
implantam no seu dia a dia. 
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Os planos funcionais indicam os recursos com os quais a TI pode con¬ 
tribuir, quando e onde. Isso tem impacto na arquitetura de aplicações, na 
infraestrutura de serviços, na organização de TI, na estratégia de sourcing e em 
todos os demais elementos do modelo. 

Uma vez de posse dessas informações, deve-se avaliar o portfólio de TI 
(contendo projetos, serviços, ativos e aplicações) da empresa, de forma a veri¬ 
ficar se cada um dos programas e ações previstas para uma função de negócio 
já está respaldado ou se há espaço para propor novas aplicações e melhorias 
sobre aquelas já existentes. 

Ao analisar um plano funcional, deve-se sempre pensar tanto nas necessi¬ 
dades da operação da função como na gestão da operação da função. Ainda 
no exemplo de marketing, podemos sugerir um projeto para permitir que os 
colaboradores do marketing consigam implantar e monitorar seus progra¬ 
mas e suas campanhas, o que faz parte da rotina operacional de uma área 
de marketing. Entretanto, esta área precisa saber o retorno sobre o investi¬ 
mento (ROI) das respectivas campanhas, visando corrigir rumos e melhorar 
as abordagens futuras de cada campanha. Isso é uma necessidade gerencial. 

Outra abordagem é o desdobramento dos objetivos de TI a partir do Mapa 
Estratégico e do Balanced Scorecard (BSC) da empresa. 

O Balanced Scorecard, técnica de planejamento empresarial desenvolvida 
pelos professores de Harvard Kaplan & Norton (1996), propicia o alinha¬ 
mento das iniciativas (projetos, ações, serviços) de TI aos objetivos estratégi¬ 
cos do negócio, considerando quatro perspectivas: 

□ Financeira. 

□ Cliente (no caso de TI usuário também). 

□ Processos internos (gestão de projetos, desenvolvimento, gestão de 
incidentes etc.). 

□ Aprendizado e crescimento. 

De acordo com esta técnica, o resultado financeiro é a satisfação do cliente, 
que continua a usar os serviços e/ou produtos da empresa, cuja experiência de 
consumo dos serviços e/ou dos produtos depende dos processos internos, os 
quais, por fim, são apoiados pelo aprendizado e crescimento (recursos huma¬ 
nos, conhecimento, patentes etc.). 

O BSC demonstra uma relação de causa e efeito e é uma poderosa ferra¬ 
menta de planejamento e de gestão de desempenho por toda a organização. 
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Se sua empresa já usa esta técnica, aproveite e faça o Balanced Scorecard da 
área de TL Vide mais sobre esta técnica no capítulo 12. 

Por fim, devem ser avaliados os princípios de TL O alinhamento estra¬ 
tégico deve considerar os princípios de TI para projetar a arquitetura de 
TI, a infraestrutura de TI etc. Esses princípios sáo derivados diretamente da 
estratégia da empresa e das necessidades do negócio. Uma vez estabelecidos, 
servem de orientadores para o desdobramento das ações necessárias de TI em 
projetos e serviços e para o estabelecimento de políticas. 

De acordo com Weill & Ross (2004) e Broadbent & Kitzis (2005), os 
princípios de TI tratam de: 

□ Papel da TI para a empresa. 

□ Informação e dados. 

□ Padrões de arquitetura e serviços de TL 

□ Comunicações. 

□ Ativos de TL 

Alguns exemplos de princípios de TI sáo: 

□ O papel da TI é contribuir para a realização da estratégia competitiva 
da empresa (se a estratégia for liderança em custo, a TI deve aprimorar 
e/ou implantar uma arquitetura de TI que reduza o custo da operaçáo 
do negócio). 

□ Manteremos uma lista de produtos apoiados pelo suporte e vendors ha¬ 
bilitados em cada tecnologia. Usuários poderáo comprar outros produ¬ 
tos fora da lista, mas náo teráo suporte de TI (padrões da arquitetura). 

□ Nossa rede corporativa deve ser capaz de prover acesso a um grande 
conjunto de aplicações, essencial para a entrega de serviços consisten¬ 
tes aos clientes (comunicações). 

□ Usuários cujo trabalho exige mobilidade devem ter acesso somente a 
dados e informação de uso operacional necessários para as tarefas fora 
da empresa (segurança da informação). 

□ Sempre compraremos antes de construir e, quando houver compra, 
implantaremos com o mínimo de customização (gestão de ativos). 

Quando a empresa ainda náo tiver seus princípios de TI estabelecidos, 
poderá fazê-lo no contexto do alinhamento estratégico e até mesmo durante 
a elaboração do Plano de Tecnologia da Informação. 
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Os princípios servem para guiar o comportamento das pessoas e da admi¬ 
nistração da empresa em relação ao uso da tecnologia da informação. 

Um caso muito comum em empresas que não têm os princípios claros 
ocorre quando um executivo compra e instala um software fora do padrão da 
TI em seu notebook e, quando ocorre algum problema, solicita suporte. Como 
a TI não tem conhecimento e experiência com o tal software, gasta muitos 
recursos e tempo precioso para atender à demanda, em detrimento de outras 
solicitações de serviços ou resolução de incidentes, sempre ocasionando recla¬ 
mações e pequenas crises. Alguns dos princípios podem estar representados 
por políticas de uso de recursos e no catálogo de serviços da TI. 

Os princípios de TI não são para serem pendurados na parede, mas sim 
para serem usados. Devem estar alinhados ao negócio, e a razão adicional de 
sua importância é que eles afetam o custo da operação de TI. 

Os princípios de TI podem ser permanentes ou não, dependendo dos ob¬ 
jetivos e estratégias da empresa. 

A Figura 3.8 apresenta o relacionamento de objetivos e estratégias empre¬ 
sariais com os princípios de TI. 


Estratégia / Diretivas 1 
do Negócio 1 



Implicações em 1 

Projetos e Serviços 1 




> Crescer pela aquisição 
de concorrentes, obtendo 
economias de escala 

0 sistema integrado de 
gestão deve ser único para 
todas as empresas do grupo 

Projetos de implantação do I 
sistema integrado de gestão 1 
nas empresas adquiridas 1 




> Obter um time-to-market 
agressivo em relação aos 
concorrentes 

Novos software devem ter 
arquitetura flexível visando a 
incorporação de novas 
features de forma rápida 

Implantar Service Oríented I 

Architecture - SCW 1 

Implantar orientação a 1 

objetos 1 




> Expandir territorialmente 
a atuação da empresa, 
visando aumentara base 
de clientes 

Prover serviços de 
atendimento para qualquer 
cliente 

Expansão da rede e da 1 

infraestrutura de serviços 1 

para outras localidades I 


Figura 3.8 - Desdobramento de estratégias em iniciativas de TI 
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3.2.2.1.3 Entendimento dos fatores críticos de sucesso do negócio 

A identificação dos fatores críticos de sucesso também se aplica quando 
não há informação disponível sobre as estratégias da empresa. Através do en¬ 
tendimento do negócio e dos seus fatores críticos, a TI pode fazer importantes 
contribuições para a estratégia da empresa. 

Fatores críticos de sucesso são aqueles nos quais a empresa precisa ter bons 
resultados se deseja ser bem-sucedida. 

Um exemplo clássico de fator crítico de sucesso na indústria automobilísti¬ 
ca e de aparelhos domésticos é o design do produto; na indústria de fastfood , a 
limpeza do ambiente e a rapidez de atendimento; nos negócios de e-commerce, 
a segurança e a logística de entrega etc. 

Os fatores críticos de sucesso podem ser: 

□ Estruturais. 

□ de Construção. 

□ Temporais. 

Os fatores críticos estruturais referem-se àqueles que são inerentes a cada 
ramo de negócio. São os fatores qualificadores mínimos necessários e que per¬ 
mitem ao negócio sobreviver. Geralmente, o impacto da estratégia do negócio 
sobre esses fatores é o de melhoria e otimização. 

Os fatores críticos de construção estão relacionados ao atendimento de 
metas da empresa, tais como implantar uma nova fábrica, desenvolver um 
novo mercado, um novo produto, novas competências gerenciais na orga¬ 
nização, um novo processo industrial ou de gestão etc. Esses fatores críticos 
também existem para atingir um fator estrutural. 

Os fatores temporais referem-se a eventos aleatórios que afetam o negócio 
e que devem ser administrados, sob pena de perda da competitividade pela 
empresa. Um exemplo de fator crítico temporal foi o alinhamento dos custos 
de produção e dos preços dos produtos quando houve a desvalorização do 
Real, em 1999, e agora, com a desvalorização ou o crescimento da economia 
brasileira. 

A tarefa aqui consiste em, uma vez identificados os fatores críticos de su¬ 
cesso do negócio, relacionar os requisitos para TI. 

A Tabela 3.3 exemplifica requisitos de TI, identificados a partir do fator 
crítico de sucesso. 
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Fator crítico de sucesso 

Requisitos de Negócio para TI 

Time-to-market 

• Velocidade do processo de produto, desde a sua concepção até o seu 
lançamento no mercado. 

• Forte necessidade de reutilização de conhecimento disponível na 
organização. 

• Forte comunicação entre equipes. 

• Gestão do processo de desenvolvimento do produto. 

Design do produto 

• Mecanismos de suporte ao design. 

Retenção e reutilização de 
conhecimento 

• Suporte à retenção e disseminação de conhecimento. 

Processos produtivos de alto 
desempenho 

• Processo sem interrupção. 

• Processo com qualidade. 

• Processo confiável. 

• Automação do chão de fábrica. 

Logística de distribuição 

• Otimização dos meios logísticos de distribuição. 


Tabela 3.3 - Requisitos de fatores críticos de sucesso 


Aqui, os requisitos de negócio para TI também podem ser derivados para 
novas aplicações, melhorias, substituição de aplicações etc. 


3.2.2.1.4 Identificação dos requisitos para TI 

Uma vez que esta análise tenha sido realizada, é importante consolidar os 
requisitos da estrutura do negócio, seus objetivos e fatores críticos de sucesso 
em requisitos para TI. 

A Tabela 3.4 a seguir mostra os impactos para TI, considerando cada um 
dos requisitos do negócio. 


Estratégia 

empresarial 

Requisitos de Negócio para TI 

Impacto em TI 

Enfoque 

TI deve apoiar a flexibilização dos processos 
relacionados a clientes, engenharia de produto, 
gestão do conhecimento (proprietário), 
relacionamento com fornecedores e integração 
dos processos de negócio. 

• Implementar arquitetura de 
aplicações e software, que permite 
o rápido desenvolvimento de novos 
produtos. 

• Disponibilizar sistemas e software 
para engenharia de produto. 

• Implantar suporte automatizado a 
supply-chain. 














66 Implantando a Governança de TI - 4 a edição 


Estratégia 

empresarial 

Requisitos de Negócio para TI 

Impacto em TI 

Diferenciação 

TI deve apoiar a implantação de processos de 
engenharia, desenvolvimento e operação de 
serviços e produtos únicos, diferenciados, assim 
como processos robustos de relacionamento 
com clientes e uso de informações para 
desenvolvimento de novos produtos. A empresa 
necessita também ter uma plataforma flexível de 
produção para mudar rapidamente. 

0 foco em novas tecnologias da TI é sobre 
aquelas que vão criar novas oportunidades de 
negócio para a empresa. 

• Implantação de plataformas de 
desenvolvimento de produtos, 
parametrizáveis. 

• Arquitetura de software 
componentizável. 

. CRM. 

Custo 

TI deve garantir a integração de processos de 
negócio (desde o pedido até a entrega do produto 
e serviço) com o mínimo desperdicio possível. 0 
foco em novas soluções da TI é sobre aquelas que 
vão reduzir custos para a empresa. 

• Implantação de sistemas integrados 
de gestão. 


Tabela 3.4 - Identificação do impacto dos requisitos de negócio em TI 


A partir da identificação do impacto, o passo seguinte é avaliar como está 
o seu portfólio de TI em relação a esses requisitos, para encontrar as oportu¬ 
nidades de melhoria. 


3.2.2.2 Análise do Portfólio atual de TI 

A análise do portfólio atual de TI é importante para verificar os seguintes 
pontos: 

□ O que está sendo executado em termos de projetos, serviços e inova¬ 
ção (identificando o que está em dia e o que não está). 

□ Qual o backlog (o que estava previsto e não foi realizado). 

□ Quais projetos, serviços e inovações foram planejados e cancelados. 

□ Como foi a execução do orçamento de TI (se ficou dentro do previsto 
ou não). 

□ Quais serviços são fornecidos, quais os respectivos acordos de níveis 
de serviço e quais os perfis de usuários e clientes. 

□ Melhorias requeridas e que já foram registradas. 
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□ Quantidade de mudanças no portfólio no período de tempo em que 
está sendo analisado. 

Esta análise vai permitir, no momento da análise das necessidades do negó¬ 
cio e dos serviços de TI, a tomada de decisões sobre: 

□ O que deve permanecer. 

□ O que deve ser retirado ou cancelado. 

□ O que deve ser melhorado. 

□ O que deve ser suspenso. 

□ O que deve ser substituído. 

□ O que deve ser incluído. 

3.2.2.3 Entendimento da dinâmica do negócio 

O entendimento da dinâmica do negócio é crítico para determinar a capa¬ 
cidade que a TI deve ter para atender às demandas do negócio e estabelecer 
sua estratégia de serviços. 

A análise estratégica da organização e a análise do portfólio atual de TI 
fornecem os elementos para a identificação de padrões e a qualificação da 
demanda dos processos de negócio. 

A Figura 3.9 exemplifica o raciocínio de como um aumento da atividade 
de um processo de negócio aumenta a demanda pelo atendimento da Cen¬ 
tral de Serviços. 

Dessa forma, caso haja mudanças no número de clientes, produtos, ser¬ 
viços, localidades de atuação da empresa, processos de negócio, processos de 
produção, novas plantas, lojas, operações, etc., haverá um aumento pela de¬ 
manda de serviços de TI. 

Porém, esta dinâmica deve ser avaliada a partir da análise estratégica do 
negócio, visando fornecer os elementos para a definição da estratégia de ser¬ 
viços, a qual irá focar o entendimento dos perfis e segmentos de usuários dos 
serviços de TI e o tipo de serviço a ser fornecido, inclusive no tocante aos 
níveis de serviços requeridos e seus impactos em custos e riscos. 
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Figura 3.9 - Dinâmica do negócio X demanda de serviços 
Adaptado de The Cabinet Office (2011 a) 


3.2.2.4 Definição da estratégia de serviços 

Uma vez entendido o negócio e sua dinâmica, e analisado o portfólio atual 
de TI, deve-se pensar na estratégia dos serviços de TI. Esta estratégia de ser¬ 
viços consiste em: 

□ Entender o que gera valor (utilidade e garantia) para os clientes e 
usuários. 

□ Desenvolver as ofertas de serviços. 

□ Desenvolver os ativos estratégicos. 
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3.2.2.4.1 Entender o cliente 

Entender o cliente significa descobrir o que gera valor para o seu desempe¬ 
nho e quais requisitos de garantia o serviço a ser provido deve ter. 

De acordo com The Cabinet Office (2011a), os clientes detêm e operam 
configurações de ativos para criar valor para os seus clientes, sendo que esses 
ativos sáo os meios de alcançarem resultados que permitem ou melhoram a 
criação de valor. 

Para o estrategista de serviços de TI, é importante entender todos os re¬ 
sultados que o cliente tem que alcançar, sendo que aqueles resultados que 
possuem menos apoio são oportunidades de atuação de TI. 

A Tabela 3.5, adaptada de The Cabinet Office (2011a), apresenta o conceito 
de resultados do cliente. 


Categoria de 
resultados 

Declaração de resultado 

Melhoria de 
capacidades 

Tomada de decisão e ação em resposta a eventos de negócio são rápidas 

Aumento de conhecimento, habilidades e experiência para os processos de 
negócio 

Supply chain é estendido 

Melhoria do 
desempenho 

Aumento da capacidade de processamento do processo 

Diminuição do período de cobrança 

Aumento no retorno dos ativos 

Melhoria dos 

recursos 

Aumento da produtividade dos funcionários 

Aumento da flexibilidade das operações 

Redução de custos 

Diminuição de custos fixos do processo de negócio 

Diminuição do tempo de início de uma nova operação 

Redução de riscos 

Continuidade do negócio é garantida 

Processo de negócio para compiiance 


Tabela 3.5 - Exemplo de resultados requeridos pelos clientes 
Adaptado de The Cabinet Office (2011 a) 
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Portanto, para entender o cliente precisamos: 

□ Identificar os resultados de negócio para cada cliente. 

□ Avaliar se o catálogo de serviços atende de forma adequada os resul¬ 
tados de negócio de cada cliente. 

□ Se houver gaps entre o suporte fornecido pelo serviço de TI e o re¬ 
sultado requerido pelo cliente no catálogo de serviço, verificar no 
pipeline dos serviços. 

□ Se mesmo assim persistir o gap , direcionar a criaçáo de um novo ser¬ 
viço de TI ou o seu melhoramento. 

Antes de prosseguirmos com o entendimento das necessidades do cliente, é interes¬ 
sante apresentarmos alguns conceitos preliminares de gerenciamento de serviços de TI. 

A prestação de serviços de TI acontece em um “ciclo de vida do serviço”, 
que, para a ITIL [The Cabinet Office (2011a)], consiste nas fases “estratégia de 
serviço”, “desenho de serviço”, “transição de serviço”, “operaçáo de serviço” e 
“melhoria contínua de serviço” 12 . 

A estratégia de serviço tem por objetivo entender as necessidades do 
cliente e estabelecer as ofertas de serviços. O desenho de serviço, como o 
nome já diz, preocupa-se com a especificação dos serviços, em nível de de¬ 
talhes técnicos. A transição significa implantar o serviço projetado. A ope¬ 
raçáo significa operar o serviço implantado e a melhoria contínua abrange 
projetar e implantar novas características do serviço, alinhadas com as ne¬ 
cessidades do cliente. 

Uma operaçáo de serviços de TI trabalha sob um “portfólio de serviços”, 
composto de um “ pipeline de serviços” e um “catálogo de serviços”. O port¬ 
fólio de serviços representa todos os recursos presentes ou que estáo sendo 
entregues nas várias fases do ciclo de vida do serviço. O pipeline de serviços é 
composto de todos os serviços que estáo sendo projetados ou que estáo sendo 
implantados. O catálogo de serviços é um subconjunto do portfólio de servi¬ 
ços visível para os clientes e representa os serviços que estáo ativos na fase de 
operaçáo de serviços e também aqueles aprovados para serem liberados. Serve 
como meio do cliente saber quais serviços sáo providos e em que condições. 

Além do mais, o catálogo de serviços faz a ligaçáo entre as linhas de serviços 
oferecidas e os ativos dos clientes, conforme mostra a Figura 3.10 a seguir. 


12 Maiores detalhes sobre a ITIL são encontrados no Capítulo 7 deste livro. 
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Figura 3.10 - Modelo de negócio do provedor de serviços 
Adaptado de The Cabinet Office (2011 a) 


Portanto, uma vez que sabemos quais resultados os clientes desejam, deve¬ 
mos avaliar se o catálogo de serviços está atendendo a essas necessidades. Se 
algum serviço náo está atendendo, é preciso, entáo, verificar no pipeline de 
serviços. Se ainda assim existirem gaps, então devemos pensar em criar novos 
serviços ou melhorar o desempenho dos serviços já existentes. 


3.2.2.4.2 As ofertas de serviços 

O desenvolvimento de novas ofertas de serviços parte do entendimento 
das necessidades dos clientes e da análise do atendimento dos serviços atuais 
e dos serviços em desenvolvimento ou em implantação a essas necessidades. 

O desenvolvimento de ofertas de serviços depende fundamentalmente 
do entendimento do que tem utilidade para o cliente e das respectivas ga¬ 
rantias do serviço, considerando os fatores críticos de sucesso do negócio 
do cliente. 

Por exemplo, em um processo de negócio de pagamentos, os fatores crí¬ 
ticos de sucesso sáo: o processamento correto dos pagamentos, o monitora¬ 
mento do processamento dos pagamentos, a segurança do processamento dos 
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pagamentos, a guarda de registros e documentos correspondentes e a garantia 
de disponibilidade do serviço. 

Visto dessa forma, a Figura 3.11 mostra a ação criada pelo provedor de 
serviços para atender ao contexto de valor do cliente em função de seus 
ativos. 


Categorias de ativos do 
cliente 

(contexto de valor) 


Ações tomadas para criar 
valor para os clientes 
(arquétipos de serviços) 



Processo 

Conhecimento 

Ativos Financeiros 



Pagamentos são 
processados 



Transações são 
monitoradas 

0 negócio é 
conduzido com 
segurança 

Documentos e 
registros estão 
seguros 

Pagamentos são 
seguros 


Figura 3.11 - Atendendo ao contexto de valor do cliente 
Adaptado de The Cabinet Office (2011 a) 


Outro aspecto a considerar na definição da oferta é entender que o valor, 
para o cliente, está em atender aos resultados do seu negócio e também em re¬ 
mover restrições e fornecer garantias de funcionamento do serviço, de acordo 
com requisitos do negócio. 

A Figura 3.12 mostra a representação do atendimento de linhas de serviços 
às questões de utilidade para o cliente, enquanto a Figura 3.13 apresenta o 
enfoque da garantia. 
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Linhas de Serviços 

Utilidade - Parte A 

Utilidade - Parte B 

Serviços móveis no ambiente 
de trabalho 

Pessoal de campo acessa, de 
forma segura, as aplicações 
corporativas 

Ser limitado pela localização 
ou tempo 


Serviços de relatórios de 
crédito 


Prover valor 
para o cliente 
quando 


Analistas de crédito 
determinam o rating da 
pessoa que está pedindo o 
empréstimo 


Sem 


Tornar mais lento o processo 
de crédito 


Serviços de continuidade do 

0 processo de negócio 


Interrupção, perda ou falhas 

negócio 

continua a operar 


ou eventos desastrosos 


Figura 3.12 - Definição de componentes de serviços, em termos de utilidade 
Adaptado de The Cabinet Office (2011 a) 



Figura 3.13 - Definição de componentes de serviços, em termos de garantia 
Adaptado de The Cabinet Office (2011 a) 
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3.2.2.4.3 O Catálogo de Serviços 

O Catálogo de Serviços de TI é um instrumento de comunicação com 
os usuários e clientes dos serviços de TI da organização e consiste em uma 
descrição detalhada dos serviços em uma linguagem orientada ao cliente, jun¬ 
tamente com os níveis de serviço associados que a organização de TI fornece 
aos usuários e clientes internos e/ou externos. 

O Catálogo de Serviços pode estar impresso, na Intranet da empresa ou 
em um CD para consulta. Nossa sugestão é que esteja na Intranet, em um 
ambiente fácil de ser acessado e que possibilite pesquisas de assuntos, assim 
como meios de interação e solicitação de serviços e, talvez, até serviços de 
autoatendimento como, por exemplo, pesquisa de problemas e erros conhe¬ 
cidos (para que o próprio usuário possa resolvê-los sem acionar a Central 
de Serviços). 

Todas as informações contidas no Catálogo de Serviços devem estar sob 
o escrutínio dos procedimentos de segurança da informação adotados pela 
empresa. A Figura 3.14 mostra o conteúdo sugerido para o Catálogo de 
Serviços. 

Como pode ser observado, o catálogo tem uma parte genérica, com infor¬ 
mações sobre como usar o catálogo, a estrutura de TI, quem é quem em TI 
etc., e dados e informações sobre a tecnologia que a TI utiliza. 

No nosso exemplo, dividimos o catálogo em serviços a usuários (internos 
da empresa), serviços a TI (ou seja, ao pessoal da área de TI ou aos envolvidos 
com atividades de TI) e em serviços a clientes e fornecedores (caso utilizem 
sistemas da empresa, como no caso de estabelecimentos vinculados a empre¬ 
sas de cartão de crédito etc.). 

Um detalhe importante (e que não pode ser esquecido no catálogo) é a 
informação sobre quais serviços não estão disponíveis, como por exemplo su¬ 
porte a softwares e equipamentos ( notebooks , palmtops etc.) não homologados 
pela empresa. 

Este catálogo será muito útil para o estabelecimento do modelo de relacio¬ 
namento com o cliente. 
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Figura 3.14 - Um exemplo de Catálogo de Serviços de TI 
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3.2.2.4.4 Definindo os objetivos e metas de TI 

Os objetivos e metas de TI sáo derivados da: 

□ Análise e definição das necessidades do negócio. 

□ Definição da estratégia de serviços. 

□ Análise e definição da arquitetura de TI. 

□ Definição da estratégia de sourcing. 

□ Definição da arquitetura de processos de TI e organização. 

□ Definição da estratégia de segurança da informação. 

□ Definição da estratégia em relação a recursos humanos e desenvolvi¬ 
mento de lideranças e competências. 

Tais objetivos e metas são estabelecidos para: 

□ Consecução da estratégia de TI. 

□ Gerenciar os níveis de serviços. 

□ Aquisição, manutenção e implantação de aplicações. 

□ Aquisição e manutenção da infraestrutura tecnológica. 

□ Implantação e melhoria de processos de TI, inclusive automação. 

□ Sourcing. 

□ Segurança da informação. 

□ Desenvolvimento de competências e lideranças. 

A Figura 3.15 mostra os relacionamentos entre os objetivos e metas. 



Figura 3.15 - Relacionamento entre objetivos e metas 
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A estratégia segue uma abordagem de objetivos balanceados em perspecti¬ 
vas de contribuição ao negócio, cliente, processos internos e potencial (orien¬ 
tação para o futuro). Esta é uma abordagem alternativa para a elaboração do 
plano de tecnologia da informação. 

A Figura 3.16 apresenta um exemplo do desdobramento de um objetivo 
estratégico, que é o aumento da disponibilidade das aplicações críticas. 



Figura 3.16 - Exemplo de desdobramento de objetivo estratégico 


A Tabela 3.6, a seguir, apresenta exemplos de objetivos e metas da TI, ge¬ 
radas a partir do plano estratégico. 

Para a consecução dos objetivos e das metas, uma série de iniciativas e 
projetos deverá ser desenvolvida, fornecendo a base para a elaboração do port- 
fólio de TI preliminar. 
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Tipo de objetivo / meta de TI 

Descrição 

Metas da estratégia de TI (BSC) 

• Aumentar o índice de satisfação dos usuários de 80% para 
90% até dezembro de 2014. 

• Aumentar o número de projetos entregues no prazo de 80% 
para 95% até dezembro de 2014. 

• Aumentar a disponibilidade de sistemas críticos de 98,999% 
para 99,999% até junho de 2014. 

• Manter a taxa de resolução de chamados no primeiro nível 
da central de serviços. 

Acordos de níveis de serviços 

• Disponibilidade de sistemas críticos em 99,999%. 

• Taxa de entrega de projetos de sistemas no prazo em 95%. 

• Tempo de recuperação de incidentes críticos - 8 horas. 

Aquisição e manutenção de aplicações 

• Implantar a nova versão do sistema inteqrado de qestão 
até 2015. 

Aquisição e manutenção da arquitetura de TI 

• Estabelecer, até dezembro de 2014 a nova arquitetura de 
software. 

• Implantar projeto de virtualização de servidores até março 
de 2015. 

Implantação e melhoria em processos 

• Automatizar o monitoramento da disponibilidade e 
capacidade das aplicações. 

• Automatizar o processo de gerenciamento de projetos. 

• Criar base dados de métricas e indicadores de TI. 

• Documentar o processo de desenvolvimento de sistemas. 

Sourcing 

• Rever os contratos de serviços de help desk até maio de 
2014. 

• Contratar nova fábrica de software. 

Segurança da informação 

• Rever o plano de segurança da informação até dezembro 
de 2014. 

• Implantar novos dispositivos de detecção de intrusão até 
junho de 2014. 

• Implantar novos controles de segurança física no data 
center até junho de 2015. 

Desenvolvimento de competências 

• Certificar 100% dos gerentes como PMP até dezembro de 
2014. 

• Certificar 100% do pessoal de infraestrutura em ITIL 
Foundation até dezembro de 2014. 


Tabela 3.6 - Exemplos de objetivos e metas 

Durante a elaboração ou revisão do Plano de Tecnologia da Informação, as 
seguintes atividades devem ser realizadas, no tocante aos objetivos e às metas 
de TI: 
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□ Analisar os objetivos e os níveis de serviços atuais quanto ao seu 
atendimento. 

□ Avaliar necessidades de melhoria em função dos resultados observados. 

□ Avaliar se há necessidade de criar novos objetivos e metas e indicado¬ 
res correspondentes e níveis de serviço, ou alterar os atuais. 

□ Avaliar quais processos e serviços merecem mais atenção para aumen¬ 
tar o desempenho ou atender aos níveis de serviço. 

□ Estabelecer objetivos e metas para o período do plano. 

□ Desdobrar os objetivos e os níveis de serviço. 

Por fim, talvez a atividade mais importante seja avaliar se os processos 
atuais de criação de indicadores, coleta e armazenamento dos dados, geração 
dos resultados dos indicadores, análise dos resultados e comunicação dos re¬ 
sultados estão adequados para atender às necessidades da gestão da TI, em 
linha com os requisitos do negócio. 

Se a sua organização de TI não tiver um processo definido de medição e 
análise, pense em implantá-lo. 

Os indicadores de resultados de objetivos, as metas de desempenho e os 
níveis de serviços devem ser considerados como um ativo para a organização 
de TI. 

O estabelecimento dos acordos de níveis de serviço está inserido no pro¬ 
cesso de Gerenciamento do Nível de Serviço que, de acordo com a ITIL 13 , é 
o processo de negociar, definir, medir, gerenciar e melhorar a qualidade dos 
serviços de TI a um custo aceitável. 

O Gerenciamento do Nível de Serviço procura fazer um balanço entre a 
prestação de serviços e a demanda, a satisfação do usuário e/ou cliente e os 
custos de fornecer os serviços. 

Os acordos de níveis de serviço são conhecidos como SLAs ou Service Levei 
Agreements e podem ser empregados para vários serviços de TI, tanto relativos 
à prestação de serviços para a organização quanto para o relacionamento com 
os fornecedores de serviços. 

Quando são estabelecidos acordos de níveis de serviço com os fornece¬ 
dores de serviços internos, esses acordos são conhecidos como Operational 
Levei Agreements ou OLAs. No caso dos acordos com fornecedores externos, 


13 Vide Van Bon & Pieper (2004) sobre as definições da ITIL. 
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os acordos sáo conhecidos como Underpinning Contracts ou UCs (contratos 
de apoio). 

Os acordos de níveis de serviço geralmente são estabelecidos para: 

□ Serviços de sistemas (desenvolvimento, manutenção, implantação de 
pacotes). 

□ Serviços de segurança da informação. 

□ Serviços de suporte ao usuário (. Service desk , resolução de incidentes 
etc.). 

□ Disponibilidade de aplicações. 

□ Disponibilidade de infraestrutura. 

□ Outros atributos de um serviço como, por exemplo, a exigência 
de que um fornecedor implante, num prazo determinado, o nível 
2 do Capability Maturity Model Integration (CMMI) ou a ISO/ 
IEC 20000. 

Tais acordos somente podem ser estabelecidos de forma responsável se são 
conhecidos: 

□ O desempenho atual, em termos de atendimento aos níveis de servi¬ 
ço requisitados pelo usuário e/ou cliente. 

□ A capacidade, em termos da infraestrutura (tanto de recursos huma¬ 
nos como de processamento, armazenagem de dados, transmissão de 
dados em redes de comunicação locais e externas). 

□ A capacidade de prover aplicações nos prazos requeridos. 

A Figura 3.17 mostra a cadeia de acordos de níveis de serviço em uma 
organização. 

AITIL (abordada no Capítulo 7) prevê processos específicos para o geren¬ 
ciamento dos níveis de serviço. 

A definição dos Acordos de Níveis de Serviços complementa o Catálogo 
de Serviços. Entretanto, esses acordos devem ser negociados com os usuários 
e clientes em função das necessidades dos respectivos negócios, sendo que os 
acordos operacionais e com os fornecedores devem também ser balizados com 
as necessidades do negócio. 
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3.2.2.4.5 Desenvolvimento dos ativos estratégicos 

Uma vez definidos os serviços que serão prestados e os respectivos Acordos 
de Níveis de Serviços, devemos definir as diretrizes para o desenvolvimento 
dos processos de Gerenciamento de Serviços, o que compreende o desenvol¬ 
vimento de capacidades e recursos. 

Essas diretrizes irão endereçar os seguintes aspectos: 

□ Portfólio de serviços. 

□ Requisitos para o projeto de serviços. 

□ Requisitos para a transição dos serviços. 

□ Requisitos para a operação dos serviços. 

□ Capacidades em termos de processos, pessoas e sistemas de gerencia¬ 
mento de serviços de TI. 

□ Capacidade de recursos (mão de obra, instalações, hardware, comu¬ 
nicação, segurança da informação etc.). 


USUÁRIO/CLIENTE 



SLA - Service Levei 
Agreeement 

OLA - Operational Levei 
Agreement 

UC - Underpinning 
Contract 







FORNECEDOR EXTERNO 


FORNECEDOR EXTERNO 


FORNCEDOR EXTERNO 


FORNECEDOR EXTERNO 


Figura 3.17 - Cadeia de acordos de níveis de serviço 
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Essas diretrizes serão empregadas quando os processos de projeto (ou de¬ 
senho), transição e operação de serviços forem desenvolvidos e implantados, 
assim como fornecerão os elementos necessários para os projetos de planeja¬ 
mento de capacidade, análise, projeto e otimização da infraestrutura tecnoló¬ 
gica e dos processos de sourcing e segurança da informação. 


3.2.2.5 Análise e definição das necessidades do negócio 

As necessidades de aplicações, no nosso ponto de vista, são: 

□ Novas aplicações de TI. 

□ Melhorias em aplicações já existentes. 

□ Reestruturação de aplicações existentes. 

□ Substituição de aplicações existentes. 

□ Descarte de aplicações existentes. 

As entradas para a avaliação das necessidades de aplicações são: 

□ O portfólio atual de projetos, serviços e aplicações, incluindo o 
backlog. 

□ Os requisitos das estratégias e/ou dos fatores críticos de sucesso. 

□ Programas, projetos e ações dos planos funcionais da empresa. 

□ Oportunidades estratégicas e competitivas em função do uso da tec¬ 
nologia da informação. 

□ Necessidades de melhoria da qualidade das aplicações (melhoria da 
confidencialidade, integridade, disponibilidade, manutenibilidade 
etc.). 

□ Objetivos estratégicos estabelecidos pelo Balanced Scorecard da 
empresa. 

A identificação das necessidades consiste em encontrar gaps entre o portfó¬ 
lio atual de projetos, serviços e aplicações, e os requisitos das estratégias, fato¬ 
res críticos de sucesso, oportunidades estratégicas, necessidades de melhoria 
da qualidade etc. A Figura 3.18 exemplifica este raciocínio. 
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Figura 3.18 - Análise das necessidades de aplicações 


As novas soluções são identificadas a partir do momento em que não há 
nenhuma correspondência entre requisitos das estratégias, planos funcionais 
e oportunidades de uso estratégico da TI com projetos, serviços e aplicações 
do portfólio atual. 

As aplicações que devem ser mantidas sem evoluções são aquelas que 
apresentam: 

□ ALTA cobertura funcional dos processos de negócio ou dos planos 
funcionais e ALTO valor estratégico. 

□ ALTA cobertura funcional dos processos de negócio ou dos planos 
funcionais e ALTA qualidade técnica. 

As aplicações que devem ser melhoradas, substituídas ou reestruturadas são 
aquelas que apresentam: 
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□ ALTA cobertura funcional dos processos de negócio ou dos planos 
funcionais e BAIXA qualidade técnica. 

□ BAIXA cobertura funcional dos processos ou dos planos funcionais e 
ALTO valor estratégico. 

□ ALTA qualidade técnica e BAIXA cobertura funcional dos processos 
de negócio ou dos planos funcionais. 

As aplicações que devem ser descartadas são aquelas que apresentam: 

□ BAIXA cobertura funcional dos processos de negócio ou dos planos 
funcionais e BAIXO valor estratégico. 

□ BAIXA cobertura funcional dos processos de negócio ou dos planos 
funcionais e BAIXA qualidade técnica. 


As figuras 3.19 e 3.20 mostram matrizes de auxílio à avaliação do portfólio 
de TL 


Verificar possibilidade de 
reestruturar a solução ou 
adquirir ou implantar outra 
solução com adequada 
cobertura funcional 


Manter a solução ou a aplicação 



Descartar a solução ou a 


Verificar a possibilidade de 

aplicação 


criar mais funcionalidades 

Baixa 

Alta 


Qualidade Técnica da 
Solução 

Figura 3.19 - Matriz de avaliação “cobertura funcional” versus “qualidade técnica de aplicações” 
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Ampliar a solução ou 
aplicação visando maior aderência 
aos objetivos e estratégias da 
organização 


Manter a solução ou a aplicação 



Descartar a solução ou a 
aplicação 


Verificar necessidade de 
manter a solução ou aplicação 
(a manutenção exige justificativa) 


Baixa Alta 


Cobertura Funcional 

Figura 3.20 - Matriz de avaliação “cobertura funcional” versus “valor estratégico” 

Soluções ou aplicações com baixa qualidade técnica sáo um driver de custo 
de retrabalho bastante grande para uma organização de TI, pois geralmente 
deslocam esforço que poderia estar sendo empregado no desenvolvimento de 
melhorias ou na implantação de novas soluções para o atendimento aos usuá¬ 
rios em níveis mais técnicos, resolvendo incidentes. 

O valor estratégico de uma solução ou aplicação deve ser entendido como 
o seu grau de aderência a objetivos e estratégias atuais e futuros. Para ajudar 
na definição do valor estratégico da aplicação para o negócio atual, pode-se 
colocar a seguinte questão: 

Qual será o impacto para o negócio atual se a aplicação se tornar 
inoperante? 

Se a inoperância gerar imediatamente perda de receita ou problemas de 
responsabilidade civil, danos na imagem junto aos clientes, diminuição do 
rating na Governança Corporativa, colocar em risco vidas de seres humanos 
ou causar grande impacto no meio ambiente, então a aplicação é estratégica 
para o negócio atual. 
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Para saber se uma aplicação é estratégica para o suporte ao atendimento 
dos objetivos estratégicos da empresa, deve-se perguntar se ela consegue atin¬ 
gir os seus objetivos sem a aplicação. Se a resposta for negativa, trata-se de 
uma aplicação estratégica. 

Outro aspecto importante a ser analisado é o grau de utilização das aplica¬ 
ções atuais. É muito provável que um baixo nível de utilização seja decorrente 
do baixo valor estratégico ou da baixa cobertura funcional. 

Se não for nenhum desses casos, deve ser previsto como ação, no portfólio 
de TI, um trabalho de endomarketing para promover a implantação e utiliza¬ 
ção adequada da aplicação. 


3.2.2.6 Análise e definição da arquitetura de TI 

De acordo com Weill & Ross (2004), a arquitetura de TI é: 

A organização lógica para dados, aplicações e infraestrutura, representada 
por um conjunto de políticas, relacionamentos e escolhas técnicas para bus¬ 
car integração desejada do negócio e da padronização técnica. 


3.2.2.6.1 Análise da arquitetura de aplicações 

A arquitetura de aplicações foca questões como: 

□ Padronização de dados e processos (o que é e o que não é padrão). 

□ Compartilhamento da infraestrutura de dados e aplicações (o que 
deve e o que não deve ser compartilhado). 

□ Como implantar aplicações considerando a arquitetura de dados e 
processos padrões. 

□ Como as novas aplicações devem ser integradas ao legado, a portais 
etc. 

□ Padrões de acesso e saídas para os usuários. 

□ Reutilização de componentes de serviços da arquitetura. 

□ Riscos que a arquitetura representa para a inovação e crescimento do 
negócio. 
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Um aspecto importante da arquitetura de aplicações é que ela possibilita a 
visualização clara, para toda a organização, acerca de como novas demandas e 
aplicações são incorporadas. 

Por exemplo, ao solicitar uma alteração em uma funcionalidade em um 
produto que é apoiado por uma aplicação, o usuário irá saber, olhando para 
a arquitetura de aplicações, que a alteração que ele solicitou causará impacto 
nas aplicações de canais e de back-office e, talvez, nas aplicações de relaciona¬ 
mento, cobrança e faturamento. 

A busca por padronização da arquitetura de aplicações tem dois objetivos 
principais: otimizar os recursos e fornecer flexibilidade para o negócio. 

Um bom caminho para avaliar aderência é através dos princípios de TI. Se 
um dos princípios diz que: “o cliente deve ter facilidade de acesso à posição 
de seus pedidos e reclamações” e a empresa não tem um meio (provavelmente 
via Internet ou Contact Center ) para permitir esse acesso, isso significa que a 
sua arquitetura não está alinhada com o princípio e, consequentemente, com 
a estratégia do negócio. 

No Plano de Tecnologia da Informação, a arquitetura de aplicações deve ser 
validada quanto ao seu grau de aderência aos objetivos e estratégias de negócio. 

Uma observação que fazemos é que todas as organizações têm sua arquite¬ 
tura de aplicações, que pode estar “desenhada” ou não. No momento da ela¬ 
boração do Plano de Tecnologia da Informação, é prudente desenhá-la para 
fins de posterior avaliação de aderência. 

Da mesma forma como ocorre com as aplicações, deve-se entender os gaps 
e planejar a cobertura da arquitetura de aplicações, o que certamente gerará 
uma série de projetos e serviços para serem priorizados, muitos dos quais exi¬ 
gindo pesados investimentos. Uma mudança nos aspectos de padronização da 
arquitetura pode alterar aplicações existentes e estáveis. 

O uso de novas abordagens, tais como Service- Oriente d A rchitectu re 14 , pode 
facilitar a integração entre aplicações com padrões diferentes. 

A Figura 3.21 apresenta um exemplo de uma arquitetura de aplicações 
hipotética de uma empresa de serviços financeiros e a Figura 3.22, uma arqui¬ 
tetura para manufatura. 

Lembramos que cada tipo de negócio exige um tipo de arquitetura específica. 

Em função dos requisitos das estratégias, pode-se avaliar a aderência da 
arquitetura de aplicações da empresa. 


14 Service-Oriented Architecture é uma coleção de serviços que se comunicam entre si. Um serviço é 
uma função autocontida, bem definida, que não depende do contexto e estado de outro serviço. 




88 Implantando a Governança de TI - 4 a edição 


Por exemplo, se a estratégia competitiva da empresa é a liderança pelo 
menor custo, então a arquitetura deve ser orientada para uma maior padroni¬ 
zação, considerando o balanceamento entre o risco e o custo de manter essa 
arquitetura, assim como para uma maior integração de processos de negócio. 
Caso haja várias divisões de negócio em negócios diferentes, pode-se padroni¬ 
zar a parte financeira e de recursos humanos e manter as demais partes como 
estão, observando também o compartilhamento de aplicações que puderem 
ser usadas por mais de um negócio ao mesmo tempo. 

Como veremos mais adiante, a arquitetura de aplicações pode moldar a 
organização de sistemas da empresa, assim como subsidiar a revisão ou elabo¬ 
ração da Política de Segurança da Informação. 

No Capítulo 12 é abordado um framework para o desenvolvimento de ar¬ 
quiteturas relativas àTI denominado The Open Group Architecture Framework 
— TOGAF, que pode ser empregado quando houver necessidade do desenho 
ou da revisão de arquiteturas de aplicações existentes. 
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Figura 3.21 - Modelo de arquitetura de TI - Serviços 
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Figura 3.22 - Modelo de arquitetura de TI - Manufatura 


3.2.2.6.2 Análise da arquitetura de infraestrutura de TI 

A avaliação da infraestrutura de TI tem como objetivo verificar se ela está 
alinhada com os objetivos estratégicos e com os requisitos de continuidade do 
negócio e se atende à arquitetura de aplicações. 

Para a avaliação em relação ao alinhamento estratégico, devemos: 

□ Identificar novas tecnologias ou atualizações tecnológicas disponíveis 
no mercado e que atendem a objetivos estratégicos da empresa. 

□ Identificar se a infraestrutura atual permite o suporte adequado aos 
objetivos estratégicos da empresa. 

□ Avaliar o impacto das necessidades de aplicações sobre a infraestru¬ 
tura, em termos das requisições por mais capacidade de recursos ou 
mais disponibilidade ou tempo de resposta. 

□ Avaliar o impacto da arquitetura de aplicações sobre a infraestrutura. 
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□ Avaliar se a infraestrutura vem atendendo aos objetivos de desempe¬ 
nho estabelecidos anteriormente e aos níveis de serviço estabelecidos. 

□ Avaliar os riscos que a infraestrutura atual representa para a continui¬ 
dade do negócio. 

□ Avaliar se a infraestrutura atual atende aos requisitos de compliance 
internos e externos. 

As avaliações permitem verificar se há gaps que devem ser cobertos para 
atender aos objetivos do negócio. Esses gaps podem ser minimizados pela pró¬ 
pria empresa ou através da contratação de outsourcing total ou parcial. 

No modelo proposto, decidir o que passar para o outsourcing é um passo 
a ser dado mais adiante, assim como realizar as avaliações de custo-benefício. 

Aqui, estamos interessados somente nos recursos de infraestrutura. Proces¬ 
sos de TI serão vistos mais à frente, quando estivermos definindo as operações 
de serviços. 

Devemos definir neste momento: 

□ Os serviços de infraestrutura de TI requeridos pelo negócio, visando 
atender aos objetivos estratégicos, requisitos de continuidade opera¬ 
cional dos negócios e questões de compliance. 

□ Os recursos computacionais requeridos para apoiar o negócio. 

□ Como esses recursos estarão dispostos na organização. 

□ Quais novas tecnologias serão implantadas e onde serão implantadas. 

□ Quais recursos deverão ser desativados. 

□ Quais recursos deverão receber upgrade. 

□ Quais serviços e recursos serão compartilhados entre as unidades da 
organização. 

□ Requisitos e dispositivos de segurança da infraestrutura lógica e física. 

Da mesma forma que na Arquitetura de Aplicações, deve-se fazer o “dese¬ 
nho” da infraestrutura de TI. 

A Figura 3.23 apresenta um modelo de infraestrutura de TI. 
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Ciclo de Vida do Serviço (ITIL V3) 



Figura 3.23 - Infraestrutura de TI 15 


De forma análoga à definição da arquitetura de TI, a arquitetura da infra¬ 
estrutura de TI também pode ser modelada usando o TOGAR 


3.2.2.6.3 Avaliando a capacidade para atendimento à demanda 

Um dos aspectos mais importantes no momento da análise da infra¬ 
estrutura de TI é verificar se a capacidade atual atende aos requisitos do 
negócio. 

O planejamento da capacidade é feito simultaneamente à identificação de 
necessidades da infraestrutura e decorre do estabelecimento dos objetivos de 
desempenho e dos níveis de serviço. 


15 Os termos “Suporte a Serviços”, “Entrega de Serviços” e “Central de Serviços” são traduções oficiais do 
itSMF Brasil para os termos da ITIL Service Support, Service Deiivery e Service Desk, respectivamente. 
A partir da versão 3 da ITIL, tais conceitos foram distribuídos entre fases do ciclo de vida do serviço 
(conforme será detalhado no Capítulo 7). 
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No contexto da Governança de TI, o planejamento de capacidade náo visa 
somente os recursos computacionais, mas também os recursos humanos, em 
termos do esforço necessário para atender ao desenvolvimento de novos pro¬ 
jetos e à manutenção de aplicações já existentes. 

A capacidade de atendimento ao desenvolvimento de sistemas, de uma 
maneira geral, depende fundamentalmente de dados históricos de consumo 
real de esforço por aplicação, por tipo de demanda e por fase do ciclo de vida 
de desenvolvimento, assim como dos dados de produtividade. 

Quando a empresa já opera através de outsourcing de sistemas, a estimati¬ 
va de esforço é um pouco mais complexa, pois precisa ser desdobrada pelas 
etapas do ciclo de vida do desenvolvimento. Por exemplo, deve-se fazer es¬ 
timativa somente para as fases de projeto físico e programação, ou somente 
programação. 

No tocante ao planejamento da capacidade de recursos computacionais e 
de infraestrutura, precisamos de informação sobre o crescimento vegetativo 
do consumo de recursos e sobre a demanda esperada por recursos, em função 
da dinâmica do negócio, das necessidades de aplicações e serviços de TI e das 
mudanças tecnológicas. 

Em suma, o planejamento da capacidade tem como objetivo quantificar: 

□ O esforço necessário para atendimento às necessidades de aplica¬ 
ções (por função, fase do ciclo de vida, tipo de demanda, aplicação 
etc.). 

□ Os recursos computacionais necessários para atender à demanda ve- 
getativa e às expectativas de crescimento do negócio, em termos de 
processadores, armazenamento, capacidade dos dispositivos de co¬ 
municação e transmissão de dados, licenças de software etc. 

Este planejamento deve ser, de preferência, documentado. 


3.2.2.7 Definição da estratégia de sourcing 

Uma vez que já temos uma visão do que é necessário em termos de ne¬ 
cessidades de aplicações, arquitetura de TI, infraestrutura de TI e capacidade 
requerida, podemos então decidir sobre o que terceirizar. 
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Os fatores que levam uma empresa a terceirizar a TI sáo, geralmente (mas 
náo restritos a): 

□ Necessidade de focar o negócio principal. 

□ ATI está cada vez mais complexa, ou seja, um negócio para especialistas. 

□ A mudança tecnológica é muito veloz e a empresa não tem a capaci¬ 
dade de investimento para se atualizar, portanto, procura um forne¬ 
cedor cujos recursos possam ser compartilhados com outras empresas 
de forma muito rápida. 

□ O custo interno da TI é muito alto e precisa ser reduzido. 

□ Como os investimentos em TI têm um risco muito alto, é preferível 
transferi-los. 

O que geralmente as empresas terceirizam: 

□ Máo de obra especialista na modalidade de body-shopping. 

□ Serviços de data center. 

□ Serviços de Service desk. 

□ Desenvolvimento e manutenção de sistemas. 

□ Eventualmente, alguns serviços relativos à segurança da informação. 

Em alguns casos, a empresa decide por terceirizar tudo, às vezes com mais 
de um fornecedor (por exemplo, um fornecedor para a parte de operações de 
data center e infraestrutura de TI, de uma forma geral, e um ou dois fornece¬ 
dores para desenvolvimento de sistemas). 

Há outros casos em que, em função da distribuição geográfica da empresa, 
serviços locais similares aos de outras localidades são operados por fornecedo¬ 
res distintos. 

Dependendo da extensão da terceirização, a organização de TI, sua estru¬ 
tura e as competências necessárias podem ser alteradas. 

No caso de uma terceirização extensiva, os profissionais da empresa devem 
ter fortes habilidades de: 

□ Planejamento e estabelecimento dos acordos de níveis de serviço. 

□ Planejamento e estabelecimento dos contratos de apoio com os for¬ 
necedores externos. 
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□ Planejamento estratégico de TI para a empresa. 

□ Monitoramento dos projetos e das demandas. 

□ Inteligência tecnológica, através do estudo de novas tecnologias que 
podem ser empregadas para criar novos negócios e/ou vantagens 
competitivas. 

Em casos em que a terceirização é parcial, além dessas habilidades devem 
ser agregadas as habilidades de planejamento e gestão de projetos. 

Numa etapa de planejamento é necessário: 

□ Avaliar o modelo atual de sourcing (caso exista). 

□ Verificar se este modelo atende às expectativas do negócio. 

□ Identificar o que precisa ser melhorado. 

□ Identificar o que precisa ser implantado. 

Atualmente, já existem melhores práticas que apoiam processos formais 
de gerenciamento de fornecedores, como no caso do Capability Maturi- 
ty Model Integration (CMMI) - especificamente áreas de processo como 
Supplier Agreement Management e modelos específicos de sourcing como o 
eService Capability Model - eSCM (ambos os modelos serão vistos mais 
adiante). 

De acordo com Cohen & Young (2006), a estratégia de outsourcing é a 
soma das ações planejadas para cada serviço necessitado para o atendimento 
aos objetivos de negócio. É o portfólio de planos de ação de sourcing que, 
especificamente, mostra onde a empresa está e onde necessita estar dentro de 
um período, em relação à provisão de serviços, quais serviços serão providos 
interna e/ou externamente, as localidades onde serão fornecidos e a quantida¬ 
de de mudanças que serão necessárias. 

A definição da estratégia pode se basear nos modelos de sourcing apre¬ 
sentados no Capítulo 11, que trata sobre modelos de sourcing e governança 
do sourcing de TI. Você pode usar as melhores práticas desses modelos para 
estabelecer o seu próprio modelo, conforme for mais apropriado para a sua 
organização, obviamente em parceria com a área de sourcing ou compras 
da empresa. 
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3.2.2.8 Definição da arquitetura de processos de TI e organização 

Uma operação de serviço está estruturada em: 

□ Serviços e produtos de TI, como serviços de suporte, disponibilidade 
de sistemas e infraestrutura, atendimento a chamados, treinamento, 
desenvolvimento de projetos, sistemas, elaboração de planos junta¬ 
mente com os clientes etc. 

□ Processos de atendimento ao cliente - front-office. 

□ Processos de suporte ao atendimento ao cliente - back-office. 

□ Processos de desenvolvimento dos processos de front-office , back-office 
e de gestão. 

□ Processos de gestão do front-office e back-office. 

□ Biblioteca de ativos (processos, artefatos, sistemas etc.), cujos ati¬ 
vos são gerados pelos processos de desenvolvimento dos processos e 
que são usados pelos processos de front-office, back-office e de gestão, 
como, por exemplo, uma metodologia de gestão de projetos ou de 
desenvolvimento de software, artefatos do processo de gerenciamento 
de incidentes, Scripts do Service desk etc. 

□ Organização da estrutura, com responsabilidades e atribuições 
definidas. 

□ Competências requeridas dos recursos humanos no contexto da ope¬ 
ração e da estrutura organizacional. 

A Figura 3.24 mostra o esquema genérico de uma operação de serviço. 

No modelo de Governança de TI, conforme já discutido anteriormen¬ 
te, operações de serviços são aquelas relacionadas a projetos (sistemas, 
infraestrutura, processos de TI), a serviços de TI (central de serviços, ge¬ 
renciamento de incidentes, problemas, gerenciamento da mudança e con¬ 
figuração, suporte técnico etc.) e a inovações, representadas por projetos 
de novas tecnologias ou de novos processos de negócio apoiados por novas 
soluções. 

Durante o planejamento da tecnologia da informação, os processos de TI, 
a estrutura organizacional, as competências e habilidades, e os ativos de co¬ 
nhecimento devem ser avaliados perante: 
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□ As necessidades da arquitetura de aplicações. 

□ As necessidades da arquitetura de infraestrutura de TI. 

□ O catálogo de serviços. 

□ Os objetivos de desempenho e os acordos de níveis de serviço. 

□ A capacidade requerida de recursos humanos e computacionais. 

□ A política de sourcing. 



Figura 3.24 - Modelo de operações de serviços 

Este último item tem um forte impacto na arquitetura da operação de 
serviços, pois define o contorno da sua arquitetura, identificando os processos 
que ficam “dentro de casa” e os que ficam “fora de casa”, no fornecedor de ser¬ 
viços. Além do mais, a estratégia de sourcing impacta a forma como a empresa 
irá se relacionar com os seus usuários e clientes (internos e externos), assim 
como com os fornecedores. 

Dependendo da situaçáo, poderá ser necessário criar uma nova operaçáo 
de serviços para contextos de business process outsourcing , com alto conteúdo 
de tecnologia da informação. 
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Após a definição da arquitetura das operações de serviços, devem ser feitas 
as seguintes perguntas: 

□ Todos os serviços e produtos gerados pela área de TI são apoiados por 
processos operacionais e de gestão? 

□ Existem todos os processos de TI para atender às necessidades de apli¬ 
cações e da infraestrutura de TI, e ao catálogo de serviços? 

□ Os processos atuais estão adequados? 

□ São necessárias melhorias nos processos atuais? 

□ A estrutura organizacional necessita ser revista em função das ou¬ 
tras definições do plano, de novos processos ou de melhorias nos 
atuais? 

□ As competências e habilidades estão compatíveis com as necessidades 
de conhecimento dos processos de TI? 

□ Como será o relacionamento com os usuários e/ou clientes? 

□ Como será o relacionamento com os fornecedores? 

No caso específico da operação de serviços de segurança da informação, 
esta somente poderá ser definida durante o estabelecimento da política de 
segurança da informação. 

Recomendamos que, ao identificar quais os processos necessários para 
apoiar as operações de serviços, se desenhe a “cadeia de valor” de TI da sua 
organização. A Figura 3.25, a seguir, apresenta um modelo de uma cadeia de 
valor de TI e a Figura 3.26, uma arquitetura de operação de serviços de desen¬ 
volvimento de software em larga escala. 

OBS.: O TOGAF pode ser visto como ferramenta para o desenvolvimento 
dos modelos de arquitetura instanciados dos processos de TI. Neste caso, cada 
modelo de melhor prática possui ativos de arquitetura que podem ser usados 
para a estruturação dos processos de TI. Vide no Capítulo 12 a discussão 
sobre o TOGAF. 
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Figura 3.25 - Cadeia de valor da TI 


3.2.2.9 Definição da estratégia de segurança da informação 

A política de segurança da informação está associada ao risco que a TI 
representa para a continuidade do negócio e endereça alguns dos requisitos 
de compliance dos principais marcos de regulação externos como a Sarbanes- 
-Oxley e o Acordo da Basileia II. Cronologicamente, esta política somente 
pode ser determinada depois que o “desenho” de todas as arquiteturas ante¬ 
riores estiver elaborado. 

A profundidade da política de segurança da informação será tanto maior 
quanto mais interconectada estiver a empresa e mais estratégico for o papel 
que a TI representa para o negócio, já que qualquer evento de risco relacio¬ 
nado com a segurança da informação poderá trazer grandes prejuízos para a 
empresa. 
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Figura 3.26 - Arquitetura de processos de uma operação de software 


No contexto da segurança da informação, os seguintes aspectos devem ser 
considerados: 

□ A instituição de um Sistema de Gestão da Segurança da Informação 
ou Information Security Management System que contemple a organi¬ 
zação, a liderança, o planejamento, o apoio, a operação, o desempe¬ 
nho, a melhoria contínua e a conformidade com requisitos legais e 
infralegais 16 . 

□ A constituição de uma Política de Segurança da Informação 
documentada. 

□ A organização da segurança da informação. 

□ Segurança em recursos humanos. 


16 Requisitos infralegais abrangem portarias, resoluções, normativos, acórdãos, etc. 






































































































100 Implantando a Governança de TI - 4 a edição 


□ Gestão de ativos. 

□ Controle de acesso. 

□ Criptografia. 

□ Segurança física e ambiental. 

□ Segurança das operações. 

□ Segurança das comunicações. 

□ Aquisição, desenvolvimento e manutenção de sistemas. 

□ Relacionamento com fornecedores. 

□ Gestão de incidentes de segurança da informação. 

□ Aspectos de segurança da informação da gestão da continuidade do 
negócio. 

□ Conformidade. 

Em suma, se sua empresa está bastante interconectada e considera a 
TI como estratégica para os negócios, mas ainda não tem uma política de 
segurança da informação, é importante pensar em criá-la, começando por 
uma análise de vulnerabilidades para, em seguida, selecionar os controles 
necessários. 

Se sua empresa já tiver o seu sistema de segurança da informação, então é 
importante, no processo de planejamento da tecnologia da informação, ava¬ 
liar se o que está sendo feito está de acordo com o planejado, qual avanço 
precisa ser feito e quais novidades precisam ser implantadas. 

Apesar de ser autônomo em sua forma de condução e gestão, o Plano de 
Segurança da Informação poderia ser considerado como um adendo do Plano 
de Tecnologia da Informação. 

Os modelos de segurança da informação, representados pelas normas 
ISO da série 27000, podem ser uma base para se estabelecer a política de 
segurança da informação. Vide o Capítulo 10 para maiores detalhes sobre 


o assunto. 
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3.2.2.10 Consolidação do portfólio preliminar de TI 

Uma vez que todos os objetivos, metas e níveis de serviços, assim como os 
respectivos projetos e iniciativas, foram definidos, podemos agora consolidar 
as necessidades. Esta consolidação contempla as interdependências entre os 
projetos, serviços e aplicações, as quais são importantes para a priorização dos 
investimentos. 

A consolidação pode ser representada de várias formas, seja funcionalmen¬ 
te por operação de serviço, por tipo de projeto, serviço ou aplicação, por área 
ou unidade de negócio, por perspectiva do Balanced Scorecard etc. 

A Figura 3.27 apresenta as possibilidades de consolidação das necessidades, 
enquanto a Figura 3.28 apresenta um exemplo de matriz de relacionamento 
entre as iniciativas. 

Através de matrizes como as dos exemplos das figuras citadas, podemos 
realizar agrupamentos de projetos, serviços e aplicações em função da sua 
interdependência. A adoção de níveis de agrupamento dessa natureza poderá 
ajudar bastante quando for o momento de decidir sobre a priorização. 
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Figura 3.27 - Classificação das necessidades 
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Figura 3.28 - Matriz de relacionamento de iniciativas 


3.2.2.11 Definição do orçamento 

O orçamento de TI é o resultado das estimativas de investimentos dos 
novos projetos, serviços e inovações, juntamente com a estimativa de despesas 
correntes, em função do que já está em operaçáo. 

Geralmente, o orçamento de uma organização é realizado por cada unida¬ 
de, que pode ser um centro de custo ou um centro de receitas. 

ATI, infelizmente, ainda é tratada como centro de custos. 

As rubricas típicas sáo: 

□ Despesas com pessoal próprio. 

□ Despesas com serviços de terceiros. 

□ Serviços de treinamento e capacitação. 

□ Aluguéis de equipamentos. 

□ Manutenção de equipamentos. 

□ Aluguéis de instalações. 

□ Manutenção das instalações. 
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□ Despesas de leasing de equipamentos. 

□ Despesas de amortização. 

□ Serviços de comunicações. 

□ Aquisição de software (produtos de software e novos desenvolvimentos). 

□ Aquisição de instalações. 

□ Aquisição de equipamentos. 

□ Serviços de consultoria. 

□ Em grandes corporações, existem regras corporativas para a elabora¬ 
ção do orçamento de TI. É na ocasião da elaboração do orçamento 
de TI que se inicia o processo de priorização dos investimentos e da 
manutenção das despesas correntes. 

□ Os gastos previstos para o ano fiscal devem ser distribuídos mês a 
mês, rubrica por rubrica, com totalizações por mês e por rubrica. 
Na elaboração do orçamento, é possível indicar, nos investimen¬ 
tos, para quais projetos os montantes financeiros estarão sendo 
empregados. 

□ É importante que, uma vez que as prioridades sejam estabelecidas, a 
TI mostre como o dinheiro estará distribuído numa visão de Portfó- 
lio de TI. 

□ Entretanto, devemos ter mais do que a visão contábil, ou seja, tam¬ 
bém a visão gerencial. 


3.2.2.12 Priorização de investimentos 

As necessidades de projetos, serviços e aplicações devem ser priorizadas 
considerando a capacidade de investimento da empresa. Para tanto, a em¬ 
presa necessita de critérios de priorização, tais como valor estratégico, risco, 
retorno financeiro etc., que também devem classificar projetos, serviços e 
inovações. 

Sugere-se que esse processo seja feito de forma colaborativa, com a TI 
atuando juntamente com os principais gestores do negócio (pois, afinal de 
contas, a TI existe única e exclusivamente para atender ao negócio). Mais 
adiante, no item 3.3, exploraremos o que chamamos de mecanismos de de¬ 
cisão em TI. 
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O resultado da priorização dos investimentos tem como produto o Portfó- 
lio de TI, considerando os projetos, serviços, ativos e inovações que deverão 
ser implantadas ou mantidas em linha com os objetivos do negócio. 

O modelo CobiT, apresentado no Capítulo 6, pode ser uma base para o 
estabelecimento de processos de priorização e análise de investimentos de TI 
(uma vez que suas práticas de gestão incorporaram as que anteriormente esta¬ 
vam no frameivork Val IT). 


3.2.2.12.1 A metodologia AHP para tomada de decisões complexas 

A tarefa de priorizar várias iniciativas de TI é extremamente complexa e 
requer processos de tomada de decisão apoiados por métodos consistentes 
e testados. 

Decisões de priorização são primordialmente associadas ao desejo de oti¬ 
mizar o uso de recursos escassos. 

Normalmente, essas decisões envolvem múltiplos critérios ou objetivos, 
muitos dos quais são intangíveis ou sujeitos a algum risco, com uma variedade 
de propósitos ou funções, e requerem análise de trade-offs , visando selecionar 
a melhor alternativa entre várias. 

Uma metodologia interessante para ser usada na tomada de decisão 
de priorização de investimentos é a AHP (Analytic Hierarchy Process), de¬ 
senvolvida pelo renomado professor Thomas Saaty 17 , da Universidade de 
Pittsburgh. 

O processo da AHP é exemplificado pela Figura 3.29 a seguir. 
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Figura 3.29 - Processo da metodologia AHP 


17 Saaty (1999). 
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De acordo com esta metodologia, a construção do modelo consiste na 
identificação e/ou estruturação dos objetivos estratégicos do negócio. Em se¬ 
guida, são estabelecidos pesos para os objetivos estratégicos, mostrando seu 
grau de importância, impacto no negócio, cobertura estratégica etc. 

Na sequência, cada um dos projetos, serviços e aplicações (ou agrupamen¬ 
to destes) é pontuado conforme a intensidade de seu alinhamento com os 
objetivos estratégicos. 

O próximo passo é procurar a otimização da seleção de projetos, serviços 
ou inovações (ou agrupamento), maximizando a alocação de recursos. 

Por fim, os resultados são comunicados aos grupos envolvidos. Este pro¬ 
cesso pode ser repetido, alterando-se as premissas de peso para os objetivos 
estratégicos até conseguir um conjunto aceitável de prioridades. 

Como resultado desse processo de priorização, é possível construir o port- 
fólio de TI, que guiará o dia a dia das operações de serviços, de forma alinhada 
com as estratégias do negócio. A Figura 3.30 mostra este processo de construção. 




Figura 3.30 - Resultado do processo de priorização 
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3.2.2.12.2 Modelos de análise de investimentos aplicados àTI 

Como parte do processo da metodologia, é importante avaliarmos o re¬ 
torno financeiro do projeto, serviço ou aplicação. Entretanto, em algumas 
situações, outros critérios podem decidir pela continuidade do projeto, inde¬ 
pendentemente do risco e do retorno financeiro. Urgências competitivas, mu¬ 
dança de legislação e requisitos de regulação podem exigir o desenvolvimento 
de projetos que aparentemente não são rentáveis do ponto de vista econômico 
e financeiro. 

Para tanto, existem vários modelos que podem ser utilizados. Eles são 
categorizados em modelos financeiros tradicionais, modelos qualitativos 
e modelos probabilísticos. 

A seguir é feita uma breve descrição de cada modelo. No próximo tópico 
desta seção, comentaremos as situações nas quais cada modelo é mais apro¬ 
priado, conforme a natureza do projeto. 


lodelos tradicionais de retorno do investimento 


Taxa Interna de Retorno do Investimento 

Por este modelo, a taxa de retorno para o projeto ser considerado viável 
deve proporcionar um rendimento próximo ao que seria obtido emprestando 
dinheiro à taxa básica de juros determinada pelo Banco Central. 

Isto significa que vale mais a pena investir no projeto do que investir no 
mercado financeiro, ou seja, que o retorno do projeto será maior. 

Para obter a taxa interna de retorno, deve-se projetar o fluxo de caixa (en¬ 
tradas e saídas) ao longo da vida útil do projeto e dos seus resultados e trazer 
esses valores ao valor presente (netpresent value). A fórmula para a determina¬ 
ção do valor presente é: 


PV = 


FV 

a +iy 


FV é o valor futuro do fluxo de caixa acumulado, I é a taxa de juros equi¬ 
valente e n é o número de períodos de tempo (meses, anos) do fluxo de caixa. 
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Economic Value Added (EVA) 

Como métrica, representa o lucro operacional líquido menos o custo do 
capital. Utilizando este modelo para avaliar a implantação de um ERP, por 
exemplo, o analista deve levar em consideração todos os investimentos, tais 
como desembolsos iniciais de caixa, custos de manutenção e custos de trei¬ 
namento internos e externos, e compará-los com os benefícios, redução de 
custos ou aumento de receita. Este método faz com que os administradores 
deem atenção ao gerenciamento eficiente dos ativos (capital) e à receita. Vide 
Stern & Stewart Co (www.sternstewart.com). 

Total Cost ofOwnership (TCO) 

Orientado para aquisição de recursos de tecnologia. Esta técnica, desenvol¬ 
vida pelo Gartner Group, procura selecionar a alternativa de menor custo to¬ 
tal ao longo da vida útil do recurso. Custo total associado ao recurso significa 
o somatório dos custos de aquisição, manutenção, treinamento, depreciação, 
suporte a usuários, infraestrutura de suporte e assim sucessivamente. Vide 
Gartner Group (www.gartner.com). 

Total Economic Impact (TEI) 

É uma metodologia de suporte à decisão projetada para tratar risco e fle¬ 
xibilidade. Na análise, o analista deve avaliar custo, benefício e flexibilidade e 
determinar o risco de cada fator. 

A análise de custo leva em consideração a abordagem do TCO, a análise de 
benefícios considera a contribuição estratégica para o negócio e a análise 
de flexibilidade emprega a metodologia de opções futuras que tenta esta¬ 
belecer valores de opções que podem ser exercidas no futuro (os leigos em 
finanças já ouviram falar em Mercado de Opções). Vide Forrester Research 
(www.forrester.com) . 

Rapid Economic Justification (REJ) 

É uma metodologia desenvolvida e mantida pela Microsoft. Similar à TEI, 
é estruturada em cinco etapas: definição do propósito do estudo e objetivos 
do negócio com o uso da tecnologia da informação, descrição da situação 
de negócio ou problema que necessita de uma solução, execução da análise de 
custo e benefício para cenários, execução da análise de risco e execução dos 
cálculos financeiros. Vide Microsoft (www.microsoft.com). 
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Modelos qualitativos 


Balanced Scorecard 

Vide Capítulo 12 para maiores detalhes sobre este modelo de gestão. 

Information Economics (IE) 

Esta metodologia tem por objetivo fornecer um método neutro para ava¬ 
liar portfólior de projetos e a alocação de recursos, onde eles podem gerar os 
maiores benefícios. Na realidade, este método estabelece prioridades de pro¬ 
jetos dentro de um portfólio. 

A metodologia pressupõe que cada linha de negócios tenha pelo menos 
dez fatores de decisão, que podem ser adicionados, excluídos ou alterados 
conforme mudam as prioridades. Esses fatores são avaliados pelo pessoal de 
tecnologia da informação e pelos gerentes de linha conforme sua importância 
para o negócio, se positiva ou negativa. Os projetos de tecnologia da infor¬ 
mação são então avaliados em relação aos fatores de decisão. Como resultado, 
cada projeto recebe uma nota que demonstra sua posição de importância no 
portfólio. Vide CIO magazine (www.cio.com). 

Gestão de Por fólio 

Esta abordagem parte do pressuposto de que os projetos não são somente 
custos, e sim ativos que devem ser gerenciados segundo os mesmos critérios 
utilizados para a gestão de portfólior de investimentos, ou seja, levando em 
consideração, além do custo, os benefícios e riscos. 

Isso significa que todo novo projeto deve ser categorizado de acordo com 
um portfólio de projetos, e que cada categoria deste portfólio deve apresentar 
uma combinação diferente de resultados para o negócio. 


Modelos quantitativos 


Real Options Valuation (ROV) 

O objetivo da metodologia é quantificar valores no tocante à flexibilidade. 
É uma técnica aplicada para aquisições, fusões, leasing e investimentos onde 
existe um alto grau de incerteza. 

No início da década de 90, começou a ser utilizada para projetos de tecno¬ 
logia da informação, principalmente em função das tecnologias emergentes. 
Vide CIO magazine (www.cio.com). 
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Applied Information Economics (AIE) 

Esta técnica combina teoria de opções, teoria de gestão de portfólio, mé¬ 
todos tradicionais como Taxa Interna de Retorno e um conjunto de técnicas 
atuariais para quantificar resultados incertos e gerar uma curva de resulta¬ 
dos esperados, considerando risco e retorno. Vide Hubbard Decision Research 
(www.hubbardresearch.com). 

A Tabela 3.7 mostra alguns critérios para selecionar o método de avaliação 
mais adequado ao tipo de projeto, serviço ou aplicação a ser avaliada. 


Tipo de Aplicação da Avaliação do Projeto 

Método de Avaliação 

Projetos cuja incerteza é pequena (os riscos são conhecidos e 
gerenciáveis) 

Taxa de retorno interna 

Contribuição de TI para a empresa 

EVA 

Projetos de aquisição de recursos 

TCO 

Análise de cenários de resultados de projetos 

TEI 

Avaliação de um projeto simples 

REJ 

Priorizar projetos 

IE 

Portfólio de projetos 

Gestão de portfólio 

Projetos cuja incerteza é grande 

ROV e AIE 


Tabela 3.7 - Tipos de métodos de avaliação 


3.2.2.12.3 Parâmetros típicos a serem usados para avaliações de 
investimento 

A Tabela 3.8 apresenta alguns parâmetros que devem ser considerados 
quando se empregam os métodos de avaliação de investimento. 


Se o projeto for de... 

Parâmetros típicos 

Processo de TI 

• Redução do retrabalho (esforço do homem-mês x custo com encargos). 

• Redução ou minimização do risco (qual parte da operação da empresa ou 
instituição pode parar e qual a perda financeira). 

• Redução de atrasos de entregas (redução do retrabalho e custos financeiros e 
contratuais de atraso). 

• Aumento da produtividade (significa redução de custo). 
















110 Implantando a Governança de TI - 4 a edição 


Se o projeto for de... 

Parâmetros típicos 

Infraestrutura de TI 

• Redução ou minimização do risco (qual parte da operação da empresa ou 
instituição pode parar e qual a perda financeira). 

• Custos de responsabilidade civil. 

• Perda de receita pela perda de clientes. 

• Custo total de propriedade (custo do recurso durante a sua vida útil). 

Substituição ou 
atualização de 
equipamentos 

• Aumento da produtividade (custo unitário da unidade de produção sofre 
redução). 

• Redução do custo total de propriedade. 

Ferramentas de gestão 
de TI 

• Redução no custo de processos (deve haver dados do custo por atividade no 
processo). 

• Eliminação de mão de obra de “apoio”. 

• Redução de risco (quanto dinheiro a empresa perderá se não gerenciar 
adequadamente a TI). 

ERP - Enterprise 
Resource Planning 

• Redução de custos do processo (eliminação de etapas de processos manuais). 

• Redução de mão de obra pela integração de processos. 

• Aumento de produtividade no chão da fábrica (redução do custo unitário do 
produto). 

• Atendimento de forma mais rápida à demanda (deixando de perder receita). 

• Melhor aproveitamento do material em processo (redução de custos de estoques 
em processo). 

• Melhoria da qualidade do produto (redução dos custos das não conformidades e 
redução de refugos). 

Desenvolvimento de um 
novo produto 

• Aumento da receita com o novo produto (potencial de mercado x preço unitário). 

• Aumento da lucratividade da empresa (receita - despesas operacionais). 

Supply-chain 

• Diminuição do número de fornecedores (redução do custo de controle). 

• Redução do custo de estoque. 

• Redução do custo financeiro. 

• Redução do ciclo de tempo de produção (aumento da produtividade). 

• Redução do custo de aquisição de insumos. 

• Melhoria da qualidade dos produtos dos fornecedores (implica em redução do 
refugo pela empresa). 

CRM - Customer 
Reiationship 

Management 

• Foco em produtos de interesse do cliente (aumento da rentabilidade da operação 
como um todo). 

• Redução no custo de vendas (menor esforço para vender). 

• Diminuição do custo e receita pela perda de cliente. 

Business Intelligence 

• Maior rapidez na tomada de decisão. 

• Maior produtividade gerencial. 

• Forte apoio à estratégia da empresa. 

• Foco em produtos e operações mais rentáveis. 

Gestão do 
conhecimento 

• Redução do custo de projetos (a não reinvenção da roda diminui retrabalho e, 
portanto, custo de recursos). 

• Redução do custo de treinamento. 

• Redução do custo das operações. 

• Redução no custo de desenvolvimento de projetos. 

• Redução do custo de recuperação de desastres. 

• Pode criar diferencial para a empresa em termos de inovação. 
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Se o projeto for de... 

Parâmetros típicos 

Customer care 

• Aumento da fidelização do cliente (significa aumento da receita). 

e-business 

• Redução de custos da operação como um todo (deve haver dados dos custos 
por atividade e processo). 

• Redução do custo de operações de front-office. 

• Redução do custo de transações. 


Tabela 3.8 - Parâmetros de análise de investimento em TI 


3.2.2.13 Portfólio de TI aprovado 

O resultado final do processo de planejamento da tecnologia da informa¬ 
ção é o novo portfólio de TI, que deverá ser implantado no período determi¬ 
nado pelo plano. 

Os objetivos do portfólio de TI são: 

□ Comunicar as prioridades de investimento de TI da empresa. 

□ Mostrar os riscos dos investimentos em TI. 

□ Eliminar a redundância nas iniciativas de TI. 

□ Otimizar recursos alocados à TI. 

□ Monitorar as iniciativas de TI. 

□ Balizar mudanças de prioridades da empresa que são refletidas em TI. 

□ Ser o elo entre a estratégia, os objetivos do negócio e as iniciativas de TI. 

O portfólio permite uma melhor comunicação entre TI e o negócio, já que, 
como premissa, ele deve ser representado em uma linguagem familiar ao negócio. 

A Tabela 3.9 mostra o impacto da falta de um portfólio de TI. 


0 que significa não ter o 
Portfólio de TI 

Resultados no curto 

prazo 

Resultados para 
o negócio 

As pessoas relutam em cancelar os projetos. 
Novos projetos são adicionados sem foco e 
objetivos claros. 

Custos crescentes em 

TI. 

Aumento do time-to-market. 

Altas taxas de falhas nos produtos 
e serviços. 

Seleção dos projetos com base na emoção. 

Os bons projetos são 
deixados de lado. 

Poucos produtos são ganhadores. 

Não há critérios estratégicos para a seleção 
de projetos. 

Projetos sem 

direcionamento 

estratégico. 

Novos produtos não estão 
alinhados com a estratégia. 


Tabela 3.9 - Impacto da ausência do portfólio de TI 
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3.2.2.13.1 Tipos de projetos, serviços e ativos do Portfólio de TI 

O Portfólio de TI é composto náo somente por projetos, mas também 
por serviços e ativos. O portfólio tem que englobar todos os itens de inves¬ 
timento e custeio das atividades de TI na organização, estejam esses na área 
de TI ou náo. 

□ Projetos : podem ser, por exemplo, a implantação de um pacote de 
ERP, uma manutenção evolutiva substancial em um sistema, o desen¬ 
volvimento de um sistema, a implantação de um escritório de proje¬ 
tos de TI ou de um processo de gestão de configuração, o estudo de 
uma nova tecnologia etc. 

□ Serviços : podem envolver, por exemplo, a troca do software antivírus 
da empresa, a implantação do upgrade do sistema operacional, a ma¬ 
nutenção dos desktops , serviços de Service desk , treinamentos de cons¬ 
cientização em segurança da informação para os usuários, instalação 
de equipamentos e softwares de suporte, atendimento a incidentes de 
falhas na infraestrutura, em sistemas e na segurança da informação, 
assim como serviços de administração da TI etc. (observe que os ser¬ 
viços podem ser direcionados para os usuários e clientes externos, ou 
para consumo interno de TI). 

□ Ativos : referem-se a toda a infraestrutura de TI, compreendendo 
computadores, servidores, dispositivos de armazenagem, equipamen¬ 
tos de comunicação, de segurança, as instalações e equipamentos de 
apoio, sistemas operacionais, software de aplicativos, softwares de su¬ 
porte etc. 

□ Inovações : referem-se a todas as soluções baseadas em novas tecnolo¬ 
gias ou tecnologias emergentes que agreguem valor ao negócio, assim 
como uma nova solução para um processo de negócio que crie um 
diferencial para os produtos e serviços da organização. 

Geralmente, a forma como os investimentos são distribuídos pelo 
Portfólio de TI é fortemente influenciada pelas estratégias adotadas pela 
organização. 
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3.2.2.13.2 Alternativas de classificação e representação do Portfólio de TI 

Há várias alternativas de classificação do Portfólio de TI na literatura, algumas 
delas utilizando mais a linguagem de TI e outras a linguagem de negócio. 

Dentro dessas alternativas, uma que nos parece adequada é a proposta feita 
por Benson, Bugnitz & Walton (2004). 

Conforme esses autores, o Portfólio de TI é dividido em dois portfólios, 
um mostrando os novos investimentos e outro mostrando o custeio das apli¬ 
cações e ativos existentes e em uso pela empresa. Adicionalmente, sugerem 
uma classificação em termos de negócio. 

Na perspectiva de TI, o portfólio é classificado em aplicações, serviços, 
infraestrutura e gestão. Esta última engloba não somente os custos de gestão 
de TI, mas também os custos de processo e organizacionais. 

Na perspectiva do negócio, é classificado como sendo estratégico, fábrica, 
nova estratégia e obrigatório: 

□ Estratégico : compreende os investimentos que têm impacto direto 
sobre o desempenho da empresa. 

□ Fábrica : investimentos necessários para a continuidade do negócio, 
para manter as portas abertas. 

□ Nova estratégia : investimentos que poderão ter impacto no desem¬ 
penho futuro da empresa, em termos de novos negócios, novos pro¬ 
dutos etc. 

□ Obrigatório : são investimentos requeridos por legislação ou 
compliance. 

A Figura 3.31 mostra esta proposição. 

Entretanto, para fins de gestão por parte do CIO, já que o Portfólio de 
TI deve ser o principal instrumento de alinhamento da estratégia com o dia 
a dia da área de TE julgamos que sejam necessárias ainda duas classificações 
adicionais: uma funcional do negócio e uma funcional de TI. 

A primeira decorre do fato de que o CIO precisa saber sobre a sua de¬ 
manda e, principalmente, sobre quem demanda e quanto dos recursos será 
alocado para cada área da empresa. A visão funcional de TI é importante por 
motivos de gestão orçamentária e de investimentos da área de TI. As figuras 
3.32 e 3.33 mostram respectivamente essas perspectivas. 
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Devemos estar atentos, todavia, para as três etapas principais do processo 
de construção do Portfólio de TI. A primeira etapa ocorre quando “consoli¬ 
damos as necessidades”, a segunda quando priorizamos os investimentos e 
tentamos fazer a alocação ótima dos recursos financeiros frente às diversas 
demandas que chegam à TI, e a terceira quando fazemos a representação do 
Portfólio de TI conforme as várias visões requeridas. 


Portfólio da 
perspectiva 
de TI 


Aplicações Infraestrutura Serviços Gestão 


Portfólio 

Existente 

Portfólio de 
Aplicações 

Portfólio da 
infraestrutura 

Portfólio de 
seriviços 

Portfólio de gestão 


Portfólio de 
Investimento 

Portfólio de 
desenvolvimento e 
aquisição de 
aplicações 

Portfólio de 
desenvolvimento 
da infraestrutura 

Portfólio de 
desenvolvimento 
de serviços 

Portfólio de 
desenvolvimento 
de gestão 
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Serviços 
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Figura 3.31 - Perspectivas de portfólio de TI 
Adaptado de Benson, Bugnitz & Walton (2004) 


A representação final do Portfólio de TI é que vamos usar no dia a dia da 
gestão de TI e no controle das iniciativas de TL 

Como você poderá notar, no portfólio funcional de negócios não há o 
portfólio de gestão, pois este é de exclusividade da área de TL Já no portfó¬ 
lio funcional de TI ele aparece novamente. 
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Figura 3.32 - Portfólio de TI com perspectiva funcional do negócio 
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Figura 3.33 - Portfólio funcional de TI 
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3.2.2.13.3 Como tratar as manutenções de sistemas no Portfólio de TI 

Por manutenção de sistemas entendemos como: 

□ Melhorias em sistemas legados. 

□ Implantação de requisitos legais em sistemas legados. 

□ Adaptação de sistemas legados às novas plataformas tecnológicas. 

□ Otimização de desempenho de sistemas legados. 

Tais tipos de manutenções, dependendo do seu porte, podem ser manu¬ 
tenções programadas. 

Por manutenção emergencial, entendemos um “serviço” de ocorrência 
aleatória, que deve ser atendido primeiramente pelo Service desk da empre¬ 
sa, de forma não programada, enquanto as outras manutenções podem ser 
programadas. Manutenções emergenciais geralmente são relacionadas a fa¬ 
lhas e defeitos em aplicações que causam inoperância em processos de negó¬ 
cio ou que expõem a imagem da empresa e/ou dos clientes, fornecedores e 
colaboradores. 

Geralmente, as organizações de software têm dificuldade de lidar simulta¬ 
neamente com manutenções programadas e não programadas, pois é sempre 
a mesma equipe que atende à solicitação. 

Uma forma de lidar com essa questão quando estamos construindo 
o portfólio de TI é trabalhar com o conceito de estimativa de horas de 
serviços para atendimento às pequenas manutenções e às manutenções 
emergenciais. 

Dessa forma, ao elaborar o portfólio na visão funcional de negócio, pode¬ 
mos, com base em registros históricos, estimar quantas horas de análise e/ou 
programação serão necessárias para atendimento a uma área funcional dentro 
de um período estipulado e registrar esta informação no portfólio. É usual, 
nesses casos, estipular uma capacidade fixa para atendimento a esse esforço 
previsto. 

No caso de manutenções de maior porte, essas podem estar listadas indivi¬ 
dualmente no portfólio de aplicações. 

Caso seja aplicável, poderão ser também representadas no portfólio de 
aplicações as releases das aplicações. Algumas empresas trabalham com o con¬ 
ceito de releases , nas quais são agrupadas as manutenções programadas a partir 
de solicitações dos usuários. Se você tem um histórico do custo de cada release 
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e a quantidade delas no ano, você pode estimar os custos de manutenção de 
sistemas no seu Portfólio de TI. 

Por exemplo, é muito comum a chegada de solicitações de serviços dos 
usuários para a elaboração de novas formas de extração de informações e que, 
geralmente, demandam muito pouco esforço para serem atendidas. O concei¬ 
to de release cabe muito bem nesse caso. 


3.2.2.13.4 A influência da estratégia da empresa na composição dos 
investimentos em TI 

Como cada empresa tem a sua estratégia de negócios, é muito provável 
que a composição dos investimentos e custeios no Portfólio de TI apresente 
variações. 

Além do mais, o próprio tipo de negócio e o estágio em que se encon¬ 
tra o uso de TI na organização também poderão determinar variações no 
Portfólio. 

Por exemplo, uma empresa cujo relacionamento com seus fornecedores 
é estratégico para o negócio rotulará uma possível implantação de uma apli¬ 
cação de supply cbain como “Estratégico”. Ao contrário, uma empresa que já 
resolveu esse problema classificará os investimentos na manutenção da sua 
aplicação de supply cbain como “Fábrica”. 

O que queremos dizer é para você tomar cuidado ao fazer benchmarking 
com outras organizações ou colegas sobre os gastos de TI. Procure entender o 
estágio de maturidade em TI em que se encontra a empresa com a qual está se 
comparando, as suas estratégias, posição de mercado etc. 

Você irá encontrar situações em que uma empresa do mesmo ramo de 
negócio está gastando alguns pontos percentuais a mais em TI do que a sua 
empresa. Possivelmente, a empresa concorrente está desenvolvendo novos 
produtos, mudando de plataforma, abrindo novos mercados, ou seja, com 
uma estratégia diferente da sua. 

O Plano de Tecnologia da Informação pode ser documentado e servir 
como um guia para a gestão da TI da empresa, principalmente no que diz 
respeito às premissas e análises que levaram ao novo portfólio. 

O portfólio é o elo entre a estratégia de negócio e as iniciativas da TI, 
constituindo-se em um dos principais instrumentos para garantir que somen¬ 
te projetos, serviços e aplicações priorizados e presentes no portfólio estejam 
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sendo executadas no dia a dia da operação. Além disso, o portfólio regula o 
relacionamento com os usuários e com os fornecedores. 

Em relação aos clientes, o portfólio diz o que pode e o que não pode ser 
feito e serve como orientador para o usuário ou cliente fazer uma nova solici¬ 
tação. O mesmo acontece com os fornecedores, pois os serviços terceirizados 
já foram previstos e constam do portfólio. 

Por fim, o portfólio deve ser comunicado para todos os integrantes da TI da 
empresa, no sentido de alinhar expectativas dos colaboradores em relação a me¬ 
tas e objetivos, ou seja, ao que a empresa espera deles em termos de resultados. 


3.2.2.14 Plano de TI - Negócios 

O Plano de TI pode ser subdividido em dois, um voltado para o negócio e 
outro para os projetos e serviços específicos de TI. 

O Plano de TI para negócios deve conter: 

□ Projetos de desenvolvimento e implantação de sistemas, soluções de 
ERP, CRM, Contact Center etc. 

□ Projetos de soluções específicas e inovadoras de segurança da in¬ 
formação, como identificação biométrica, sistemas de vigilância 
etc. 

□ Projetos de adoção de novos paradigmas tecnológicos (por exemplo 
cloudcomputing, BigData, BYOD etc.). 

□ Projetos de melhorias em sistemas existentes. 

□ Projetos de Business Intelligence e sistemas gerenciais. 

□ Sistemas e soluções que deverão ser mantidas e as que irão ser 
descartadas. 

Esses projetos geralmente fazem parte do orçamento da área demandante 
do projeto ou da solução. 

Neste caso, quem deve fazer o Business Case é a área demandante da solu¬ 
ção, evidenciando o retorno do investimento. 

Cada unidade de negócio deve priorizar o que deseja para atender aos seus 
objetivos e aos direcionadores estratégicos estabelecidos pela alta administração. 

A priorização, em nível corporativo, de quais projetos serão realizados, é de 
inteira responsabilidade da alta administração. 
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3.2.2.15 Plano de TI - Internos 

Neste plano estão as iniciativas da área de TI para atender ao Plano de TI 
— Negócios. Deve conter pelo menos: 

□ Projetos de implantação de Governança de TI. 

□ Projetos de implantação de processos de TI. 

□ Projetos de implantação/melhoria de data center. 

□ Projetos de implantação/expansão de redes de comunicação. 

□ Projetos de segurança da informação. 

□ Projetos de desenvolvimento de competências em recursos humanos. 

□ Projetos de infraestrutura de TI. 

□ Projetos de aquisição de software de monitoramento e desempenho 
do ambiente. 

□ Sistemas específicos necessários para a gestão de TI. 

□ Projetos de estudos e prospecção de novas tecnologias. 

□ Projetos de otimização da arquitetura de software. 

□ Projeto de implantação do gerenciamento de serviços de TI. 

□ Projeto de implantação de novos serviços de TI etc. 

□ As prioridades devem estar alinhadas à estratégia de serviços de TI 
definidas anteriormente, pois são derivadas das necessidades do negó¬ 
cio, do entendimento do negócio, da análise do portfólio atual e do 
entendimento da dinâmica do negócio. 


3.2.3 Elaboração do mapa estratégico e do Balanced 
Scorecard (BSC) 

Uma alternativa ao processo de alinhamento em discussão (o item 3.2 des¬ 
te capítulo) é empregar o modelo proposto por Kaplan & Norton (1996 e 
2004) de mapa estratégico e BSC. 

Essa abordagem simplifica o processo de alinhamento estratégico, apesar 
de a implantação da estratégia ser similar ao processo discutido até agora 18 . 

Caso a organização já tenha um BSC, então o BSC de TI deve ser derivado 
deste. 


18 Vide o Capítulo 12, que detalha a método de elaboração do mapa estratégico e do BSC. 
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Para simplificar, como ponto de partida, podemos empregar a proposição 
de Kaplan (2001) para o IT-BSC, conforme mostra o mapa estratégico gené¬ 
rico elaborado pelo próprio autor, representado pela Figura 3.34. 

O mapa demonstra uma relação de causa e efeito, ou seja, para a TI contri¬ 
buir para o negócio, precisa ter excelência operacional, aliança com as unida¬ 
des de negócio e propor soluções capacitadoras e inovadoras para o negócio. 
Entretanto, para isso, precisa ter pessoas capacitadas, retê-las e desenvolvê-las, 
assim como capacitar-se em tecnologias emergentes. 

Dessa forma, objetivos de trabalhar com custos competitivos, entregar 
serviços com qualidade, fazer as coisas certas no tempo certo e atender às 
estratégias das unidades de negócio podem ser alcançados. Uma vez que esses 
objetivos da perspectiva cliente são atendidos, os objetivos de contribuição ao 
negócio também são alcançados. 




Figura 3.34 - IT BSC - Adaptado de Kaplan (2001) 


A Tabela 3.10 mostra as questões genéricas e principais de cada perspectiva 
do BSC. 
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Orientação ao Cliente 

Contribuição ao 
Negócio 

Excelência 

Operacional 

Potencial 

(Orientação Futura) 

Como os clientes 
(usuários) veem a TI? 

Como a administração 
enxerga a TI? 

Quão efetivos e 
eficientes são os 
processos de TI? 

Como a TI está 
posicionada para 
atender a desafios 
futuros? 

Missão: ser o fornecedor 
de serviços de TI 
preferido. 

Missão: obter um 
retorno adequado dos 
investimentos de TI. 

Missão: entregar 
aplicações e serviços de 
TI, efetivos e eficientes. 

Missão: desenvolver 
oportunidades para 
responder a desafios 
futuros. 

Objetivos: entregar 
serviços com qualidade, 
com custos competitivos, 
apoiar a estratégia do 
negócio, entregar e fazer 
certo no tempo certo. 

Objetivos: gerenciar os 
custos de TI com disciplina 
orçamentária, maximizar 
retorno dos investimentos 
de TI, maximizar criação 
de valor. 

Objetivos: otimizar 
processos de TI, 
gerenciara qualidade 
dos serviços; padronizar 
plataforma e arquitetura; 
entregar no prazo. 

Objetivos: atrair e reter 
talentos, desenvolver 
habilidades, desenvolver 
habilidades em novas 
tecnologias. 


Tabela 3.10 ■ BSC genérico 


Uma vez definidos o mapa estratégico e os objetivos do BSC, é hora de des¬ 
dobrar esses objetivos em iniciativas com suas respectivas metas de resultado 
e metas de desempenho. 

A Tabela 3.11 exemplifica esse desdobramento. 


Objetivo 

estratégico 

Iniciativas 

Meta de 

resultado 

Meta de 
desempenho 

Entregar 
serviços com 
qualidade 

Implantar SLAs nos 
serviços de TI. 

60% dos serviços de TI com SLA 
até dezembro de 2013. 

30% dos serviços com SLA até 
junho de 2014. 


Implantar processo 
de estimativa. 

50% dos projetos críticos 
empregaram o novo método de 
estimativa até dezembro de 2013. 

25% dos projetos com o novo 
processo até junho de 2014. 

Entregar no 
prazo 

Implantar processo 
de requisitos. 

80% dos projetos com processo de 
gestão de requisitos até dezembro 
de 2013. 

40% dos projetos com processo 
de gestão de requisitos até 
junho de 2014. 

60% dos projetos até setembro 
de 2014. 


Implantar processo 
de gerenciamento de 
projetos. 

100% dos projetos usando o 
processo de gestão de projetos até 
dezembro de 2013. 

30% dos projetos até março de 
2014. 

60% dos projetos até junho de 
2014. 


Tabela 3.11- Desdobramento de objetivos estratégicos 
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Por fim, lembramos que o BSC de TI pode ser desdobrado em BSCs para 
sistemas, operações, governança de TI, segurança da informação, serviços de 
TI etc., como mostra a Figura 3.35. 

Caso a sua organização já tenha um BSC corporativo há um pressuposto 
de que, ao fazer um BSC de TI derivado do corporativo, você já está realizan¬ 
do o alinhamento, ainda que estático, da TI. 

Ao contrário, se sua organização não tiver um BSC, mesmo assim você 
pode elaborar o BSC de TI. Entretanto, as etapas de análise estratégica da or¬ 
ganização, análise do portfólio atual e entendimento da dinâmica do negócio 
deverão ser executadas. 



Figura 3.35 - Desdobramento do BSC 


Você deve estar se perguntando: “Qual abordagem devo usar para elaborar 
o meu plano de tecnologia da informação?” 

A abordagem representada pela Figura 3.6 (processo de elaboração do Pla¬ 
no de TI, apresentado anteriormente) é adequada quando a organização ne¬ 
cessita revisitar a TI como um todo. Mas isso não acontece a todo momento. 

Nessa abordagem mais complexa, há um trabalho de maior profundidade 
quando estamos definindo os serviços, a arquitetura de aplicações, a arqui¬ 
tetura de infraestrutura, a política de segurança da informação, os mapas de 
processos de TI, a política de sourcing e assim por diante. 
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Já no caso do BSC, embora também necessitemos entender a organização, a 
parte de definição dos serviços, das arquiteturas, políticas, organização e processos 
de TI tornam-se iniciativas e metas do BSC. A Tabela 3.12 mostra essa diferença. 


Componentes do 
Plano de Tecnologia 

Abordagem 

Transformacional 

Abordagem de 

BSC 

Análise estratégica da 
organização 

Deve ser realizada. 

Deve ser realizada se não houver 

BSC corporativo. 

Análise do portfólio atual 

Deve ser realizada. 

Deve ser realizada para cotejar com 
as iniciativas propostas e derivadas 
do BSC. 

Entendimento da 
dinâmica do negócio 

Deve ser realizada. 

Não necessita. 

Definição da 
estratégia de serviços 

Aqui a estratégia é definida, assim como 
o catálogo de serviços. 

A necessidade de definir uma 
estratégia de serviços pode ser uma 
iniciativa do BSC. 

Análise e definição das 
necessidades do negócio 

Aqui são identificados os gaps da 
arquitetura de aplicações em relação ao 
que o negócio requer em função de sua 
transformação. 

0 BSC foca a estratégia de TI, 
podendo ter como uma das iniciativas 
concentrar nas aplicações que 
agreguem valor para o negócio. 

Análise e definição da 
arquitetura de TI 

Aqui são identificados os gaps da 
arquitetura tecnológica em relação 
aos requisitos do negócio e uma 
especificação da nova arquitetura é 
derivada. Um projeto derivado será então 
a implantação da nova arquitetura. 

0 BSC não faz a especificação, 
pois ela pode ser uma iniciativa 
derivada. Geralmente no escopo da 
iniciativa haverá a especificação e a 
implantação da nova arquitetura. 

Definição da estratégia de 
sourcing 

Aqui as políticas e regras e um mapa de 
processos podem ser especificados. 0 
projeto derivado será a implantação da 
política de sourcing. 

0 BSC pode gerar uma iniciativa para 
se implantar políticas e processos 
de sourcing. No escopo da iniciativa 
estará incluso que há a necessidade 
de especificar e implantar. 

Definição da arquitetura de 
processos 

Aqui são definidas a cadeia de valor e 
as especificações iniciais dos processos 
que deverão ser implantados. Derivam- 
se projetos de implantação de processos 
de TI. 

0 BSC menciona a necessidade 
dos processos de TI. Fica para a 
definição do escopo da iniciativa 
a necessidade de especificar e 
implantar os processos. 

Definição da estratégia de 
segurança da informação 

Aqui são definidos os processos, a 
arquitetura, necessidades de recursos 
específicos. 

0 BSC pode derivar iniciativas 
relativas à segurança da informação, 
mas fica para o escopo das iniciativas 
a especificação e a implantação do 
sistema de segurança da informação. 

Consolidação do portfólio 
preliminar 

Abrange todos os projetos, recursos e 
serviços. 

0 portfólio foca principalmente as 
questões internas de TI. 

Definição do orçamento 

Dever ser elaborado a partir do portfólio 
preliminar. 

Deve ser elaborado o orçamento com 
base nas quantidades do portfólio. 
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Componentes do 
Plano de Tecnologia 

Abordagem 

Transformacional 

Abordagem de 

BSC 

Priorização de 
investimentos 

Deve ser realizado a partir do orçamento 
e do portfólio preliminar. 

Idem. 

Portfólio aprovado 

Derivado a partir da priorização dos 
investimentos 

Idem. 

Plano de TI - negócios 

Deve ser elaborado. 

Geralmente as iniciativas geradas 
pelo BSC não focam os projetos de 
desenvolvimento de aplicações. 

Plano de TI - melhorias 

Deve ser elaborado. 

Geralmente as iniciativas geradas 
pelo BSC concentram-se nos 
aspectos internos da TI alinhadas 
com o negócio. 


Tabela 3.12 - Critérios de seleção da abordagem de planejamento de TI 


3.3 Mecanismos de decisão em TI 

Neste ponto, tomaremos emprestado o modelo de Weill & Ross (2004) 
sobre os arquétipos de decisão que propuseram para a TL Estes professores, 
com base numa extensiva pesquisa com 256 empresas, identificaram padrões 
de mecanismos organizacionais para a tomada de decisões em TI relativas a: 

□ Princípios de TI. 

□ Arquitetura de TI. 

□ Estratégia de infraestrutura de TL 

□ Necessidades de aplicações. 

□ Investimento e priorização. 

Os padrões identificados foram: 

□ Monarquia do negócio : neste padrão, os executivos seniores de ne¬ 
gócio tomam as decisões relativas à TL 

□ Monarquia de TI : neste padrão, os profissionais de TI tomam todas 
as decisões pertinentes à TL 

□ Feudal : neste padrão, cada área da empresa ou unidade de negócio 
decide sobre a TI de forma isolada. 

□ Federal : neste padrão, tanto a matriz, a holding ou o board , junta¬ 
mente com as unidades de negócio, tomam as decisões relativas àTI. 
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□ Duopólio de TI : neste padrão, as decisões são derivadas de acordo 
entre os executivos de TI e outros grupos de negócio. 

□ Anarquia : neste padrão, indivíduos e pequenos grupos tomam suas 
próprias decisões baseados em suas necessidades locais. 

Nessa pesquisa, os professores Weill e Ross descobriram que as empresas de 
maior desempenho na TI usam diferentes arquétipos de tomada de decisão, 
conforme o tipo de decisão. 

A Figura 3.36 apresenta os arquétipos de decisão utilizados nas três empre¬ 
sas que maiores desempenhos apresentaram com o uso da TI. 

Como já mencionamos no início do livro, as decisões de TI não são mais a 
seara somente dos executivos de TI, pois a TI permeia praticamente todos os 
negócios da empresa. Decisões relativas à TI passam a ser decisões de negócio; 
portanto, os executivos de negócio devem ser envolvidos. 
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Figura 3.36 - Arquétipos de decisão em TI de maior desempenho 
Adaptado de Weill & Ross (2004) 
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No contexto da Governança de TI, é necessário estabelecer uma matriz de 
responsabilidades e envolvimento pelas decisões de TL Nessa matriz, pode¬ 
riam ser incluídos alguns tipos de decisão a mais (principalmente no tocante 
à segurança da informação e à estratégia de sourcing ), por merecerem uma 
abordagem de compartilhamento de responsabilidades. 

Para construir a matriz, devemos identificar quem deve ser envolvido na 
formulação de alternativas e da escolha da alternativa, com relação a prin¬ 
cípios de TI, arquitetura, infraestrutura, necessidades de aplicações, investi¬ 
mentos, segurança da informação e estratégia de sourcing. 

Um lembrete importante ao estabelecer os mecanismos de decisão mais 
adequados é o de separar as pessoas que formulam a alternativa de solução das 
pessoas que, efetivamente, escolhem a alternativa mais adequada. 

Por exemplo, ao definir necessidades de aplicações, podemos estar inte¬ 
ragindo com o responsável por uma unidade de negócio; entretanto, quem 
toma a decisão sobre as prioridades de investimento é a Diretoria Executiva 
da empresa. Ou seja, para cada tipo de decisão, temos que identificar quem 
formula as necessidades e alternativas e quem decide sobre a alternativa, pois 
podem ser fóruns diferentes de decisão. 

Geralmente, as empresas usam mecanismos tais como Comitês de Projeto 
para decidir sobre prioridades de desenvolvimento ou implantação de aplica¬ 
ções e a Diretoria Executiva para decidir sobre investimentos e priorização de 
aplicações estratégicas. 

Os mecanismos de decisão são críticos para que a estratégia de TI seja 
implantada. Sem esses mecanismos, a tarefa de gerenciar a TI ficará ainda 
mais complexa e você precisará ser um “missionário” e educador em tempo 
integral. 


3.4 A ENTREGA DE VALOR 

3.4.1 Gerenciamento do portfólio de TI 

De acordo com o padrão de Gerenciamento de Portfólio do Project Ma¬ 
nagement Institute [PMI (2013b)], a gestão de portfólio é: “uma coleção de 
projetos e/ou programas e outros trabalhos que são agrupados para facilitar a 
gestão efetiva do trabalho para atender os objetivos estratégicos do negócio”. 
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Já o extinto modelo Val IT 19 do IT Governance Institute [ITGI (2008)] 
definia portfólio como: “agrupamento de objetos de interesse como pro¬ 
gramas de investimentos, serviços de TI, projetos de TI ou outros servi¬ 
ços e recursos, gerenciados e monitorados para otimizar o valor para o 
negócio 

No contexto de nosso modelo, o portfólio é gerado na fase de alinhamento 
estratégico e usado na entrega de valor e no gerenciamento de recursos. 

Na fase de entrega de valor, o portfólio é usado para o monitoramento e 
o gerenciamento de projetos, serviços e inovações e para estabelecer as regras 
sobre o que entra e sai do portfólio ao longo do tempo. 

Na fase de gerenciamento de recursos, o interesse é otimizar os recursos 
entre os projetos, serviços e inovações do portfólio. 

O portfólio de TI é o Plano de Tecnologia da Informação em sua forma 
dinâmica, como já discutido anteriormente. Ele reflete a realidade das deman¬ 
das sobre a área de TI em um determinado momento. 

Portanto, o gerenciamento do portfólio de TI na fase de entrega de valor 
significa: 

□ Monitorar e gerenciar as mudanças no portfólio de TI. 

□ Garantir que os projetos, serviços e inovações que estáo sendo desen¬ 
volvidos ou fornecidos sejam derivados do portfólio. 

□ Garantir o uso adequado dos recursos entre as demandas. 

□ Avaliar se os objetivos de retorno de investimento estáo sendo 
atendidos, a partir dos resultados da TI e dos resultados para o 
negócio. 

□ Monitorar a consecução dos projetos, serviços, inovações e ma¬ 
nutenções de recursos de acordo com os padrões de desempenho 
estabelecidos. 

□ Avaliar o impacto de mudanças do portfólio sobre a demanda de 
serviços. 

Na realidade de uma área de TI, sáo vários os atores que se envolvem no 
gerenciamento do portfólio de TI, assunto do qual nos ocuparemos mais ami¬ 
úde no Capítulo 4. 


19 Agora integrado ao CobiT 5. 
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3.4.2 Operações de serviços de TI 

Podemos entender a área de TI como um conjunto de operações dedicadas 
a prover serviços para usuários e/ou clientes externos e para a própria área 
de TI. 

Uma operaçáo de serviços deve estar aderente às necessidades da operação 
de TI como um todo, sendo que a lógica de estruturação de operações de 
serviços compreende: serviços aos usuários e clientes, requisitos de compliance 
desses serviços, níveis de serviço esperados, processos para executar e apoiar 
os serviços, o pacote de serviços a ser adotado, conhecimento para apoio aos 
processos, competências e divisáo do trabalho (que no caso é a estrutura orga¬ 
nizacional) para operar os processos. 

A Figura 3.37 apresenta a lógica de estruturação de operações de serviços 
que pode ser aplicada para qualquer tipo de serviço, inclusive de TI. 
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Figura 3.37 - Fluxo de estruturação de serviços 


Um conceito importante para a estruturação de serviços é o que chamamos 
de Pacote de Serviços . 

De acordo com a classificação sugerida por Corrêa & Caon (2002), um 
pacote de serviços é composto por: náo estocáveis essenciais, náo estocáveis 
acessórios, estocáveis com transferência de propriedade e estocáveis sem trans¬ 
ferência de propriedade. 
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□ Náo estocáveis essenciais sáo atributos do serviço que fazem parte de 
sua missão primordial. Na área de TI, por exemplo, temos como esto¬ 
cáveis essenciais a entrega dos projetos e demandas dentro do prazo, 
custo e funcionalidades acordadas. 

□ Náo estocáveis acessórios sáo atributos dos serviços que náo fazem 
parte de sua missáo principal. No caso de projetos, a possibilidade 
do usuário saber o status do projeto ou de sua demanda é um náo 
estocável acessório, porém, pode ser um elemento diferenciador ou 
de aumento de percepção da qualidade. 

□ Estocáveis com transferência de propriedade , ainda no caso de proje¬ 
tos, podem ser os relatórios impressos sobre o status do projeto, cro- 
nogramas etc., enquanto os estocáveis sem transferência de proprie¬ 
dade são recursos e instalações usados pela TI para prover os serviços 
e os sistemas de informação de apoio à gestão do projeto. 

Do ponto de vista da Governança de TI, os serviços devem ser fornecidos 
de acordo com as normas e os procedimentos da organização, os quais podem 
estar baseados nos modelos de melhores práticas (vide Capítulo 5 sobre o 
resumo dos modelos de melhores práticas). 


3.4.2.1 Projetos 

Podemos classificar os projetos de TI nas seguintes categorias: 

□ Projetos de sistemas: abrange projetos de desenvolvimento de 
novos sistemas, de manutenções evolutivas significativas em siste¬ 
mas existentes, implantação de soluções como Sistemas Integra¬ 
dos de Gestão (ERP), Customer Relationship Management (CRM), 
ManufacturingExecution Systems (automação de chão de fábrica), 
Business Intelligence, Big Data, implantação de softwares de gestão 
de TI etc. 

□ Manutenções de sistemas: abrange o conjunto de manutenções le¬ 
gais e adaptativas em sistemas de pequeno e médio porte. 

□ Projetos de infraestrutura tecnológica: abrange projetos de im¬ 
plantação de data centers, projetos de virtualização e consolidação de 
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servidores, projetos de cloud computing, projetos de rede de comuni¬ 
cações, implantação de sistemas operacionais, softwares de suporte, 
implantação de dispositivos de armazenamento de dados e softwares 
de apoio etc. 

□ Projetos de segurança da informação: abrange projetos de implan¬ 
tação de segurança lógica e física, implantação de dispositivos de se¬ 
gurança da informação, programas de conscientização e planos de 
continuidade de negócio, políticas e controles para mídias sociais e 
uso de dispositivos móveis etc. 

□ Projetos de sourcing. abrange projetos de implantação de política, 
normas e procedimentos de gerenciamento do sourcing. 

□ Projetos de processos de TI: abrange projetos de implantação de 
processos como: metodologia de desenvolvimento de sistemas, de ge¬ 
renciamento de projetos, gestão da qualidade, planejamento de TI, 
gerenciamento de serviços de TI como gerenciamento da disponibi¬ 
lidade, gerenciamento da capacidade, gerenciamento da mudança, 
processos específicos de governança de TI etc. 

□ Projetos de estrutura organizacional: abrange projetos de implan¬ 
tação de novas estruturas organizacionais na área de TI. 

□ Projetos de desenvolvimento e capacitação de recursos humanos: 
abrange projetos de capacitação dos profissionais de TI. 

Esses projetos fazem parte do portfólio de TI, sendo que, em determina¬ 
das situações, há programas (coleção de projetos). Por exemplo, a implanta¬ 
ção de processos de gerenciamento de serviços, baseados na ITIL, pode ser 
considerada como um programa, sendo que cada processo pode ser conside¬ 
rado um projeto. 


3.4.2.2 Serviços 

Podemos classificar os serviços de TI nas seguintes categorias: 

□ Serviços aos usuários: atendimento à resolução de incidentes e a 
chamados de usuários de recursos e de sistemas (geralmente esses 
serviços são fornecidos através de uma central de serviços ou de um 
belp desk). 
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□ Gerenciamento de desempenho de aplicativos: refere-se ao moni¬ 
toramento em tempo real do desempenho dos aplicativos e sistemas 
ou de avaliações periódicas para identificar causas de problemas de 
desempenho em aplicações críticas. 

□ Gerenciamento de incidentes: visa restaurar a operação normal de 
um serviço no menor tempo possível, de forma a minimizar impactos 
adversos para o negócio. 

□ Gerenciamento de problemas: visa minimizar os impactos adver¬ 
sos de incidentes e problemas para o negócio, quando causados por 
falhas na infraestrutura de TI, assim como prevenir que incidentes 
relacionados a essas falhas ocorram novamente. 

□ Gerenciamento das operações de serviços de TI: responsável pelas 
operações diárias da operaçáo como monitoração e controle, progra¬ 
mação de jobs, tarefas de backup , gerenciamento do mainframe, ge¬ 
renciamento e suporte a servidores, gerenciamento de dados, admi¬ 
nistração de banco de dados, gerenciamento de serviços de diretório, 
gerenciamento da internet/ web e gerenciamento de facilidades e data 
centers etc. 

□ Gerenciamento da rede de comunicações: responsável pelo moni¬ 
toramento e gerenciamento da rede de comunicações da organização. 

□ Serviços de segurança da informação: realiza o gerenciamento de 
acesso a sistemas e recursos de rede, monitora intrusões na rede da or¬ 
ganização e toma medidas de proteção contra essas intrusões, realiza 
atualização de aplicativos tipo antivírus etc. 

□ Serviços de suporte técnico: realiza o suporte à operação e às equi¬ 
pes de desenvolvimento de sistemas. 

□ Gerenciamento da capacidade: assegura que a capacidade da infra¬ 
estrutura de TI absorva as demandas evolutivas do negócio de forma 
eficaz e dentro do custo previsto, balanceando a oferta de serviços em 
relação à demanda e otimizando a infraestrutura necessária à presta¬ 
ção dos serviços de TI. 

□ Gerenciamento da disponibilidade: visa assegurar que os serviços 
de TI sejam projetados para atender e preservar os níveis de disponi¬ 
bilidade e confiabilidade requeridos pelo negócio, minimizando os 
riscos de interrupção através de atividades de monitoramento físico, 
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solução de incidentes e melhoria contínua da infraestrutura e da or¬ 
ganização de suporte. 

□ Gerenciamento da mudança: visa assegurar o tratamento sistemáti¬ 
co e padronizado de todas as mudanças ocorridas no ambiente ope¬ 
racional, minimizando assim os impactos decorrentes de incidentes/ 
problemas relacionados a essas mudanças na qualidade do serviço, 
melhorando a rotina operacional da organização. 

□ Gerenciamento da configuração e de ativos de serviço: abrange a 
identificação, o registro, o controle e a verificação de ativos de servi¬ 
ços e itens de configuração (componentes de TI, tais como hardware, 
software e documentação relacionada), incluindo suas versões, com¬ 
ponentes e interfaces, dentro de um repositório centralizado. Tam¬ 
bém faz parte do escopo deste serviço a proteção da integridade dos 
ativos e itens de configuração ao longo do ciclo de vida do serviço, 
contra mudanças não autorizadas. 

□ Gerenciamento do nível de serviço: visa manter a qualidade dos 
serviços de TI, através de um ciclo contínuo de atividades envolvendo 
planejamento, coordenação, elaboração, estabelecimento de acordo 
de metas de desempenho e responsabilidade mútuas, monitoramento 
e divulgação de níveis de serviços, níveis operacionais e de contratos 
de apoio (com fornecedores). 

□ Gerenciamento da continuidade dos serviços de TI: desdobra¬ 
mento do gerenciamento da continuidade do negócio, que visa as¬ 
segurar que todos os recursos técnicos e serviços de TI necessários 
(sistemas, redes, aplicativos, central de serviços, suporte técnico, te¬ 
lecomunicações, operações) possam ser recuperados dentro de um 
tempo determinado. 

□ Gerenciamento de fornecedores: gerencia fornecedores e contratos 
necessários para suportar os serviços por eles prestados, visando pro¬ 
ver um serviço de TI com qualidade transparente para o negócio, 
assegurando o valor do investimento feito. 

□ Gerenciamento financeiro: visa gerenciar o ciclo financeiro do port- 
fólio de serviços de TI, de forma a prover a sustentação econômica 
necessária para a execução dos serviços. 
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3.4.2.3 Inovações 

As inovações sáo projetos com características diferentes, considerando seu 
ciclo de desenvolvimento. 

Dependendo da inovação, ela se caracteriza mais como um projeto de pes¬ 
quisa (P&D). Projetos de pesquisa sáo formados por vários ciclos evolutivos, 
podendo durar anos. 

Na prática, os projetos de inovações sáo baseados em tecnologias já existen¬ 
tes, disponíveis no mercado, e às vezes emergentes. 

Conforme for a prática de gestáo da organização (por exemplo, se a orga¬ 
nização é reconhecida pela sua liderança tecnológica), pode haver uma cultura 
para a inovaçáo. 

As inovações em TI, particularmente, sáo criadas para melhorar os proces¬ 
sos de negócio ou para melhorar os serviços de TI. 

Seguem alguns exemplos de inovações em TI para processos de negócio: 

□ Identificação biométrica: para os processos de autoatendimento 
numa agência bancária. 

□ Sistema da receita federal: recebimento de declarações de imposto 
de renda pela Internet. 

□ Aplicações em dispositivos móveis como telefones celulares, smart- 
phones, tablets-. usados em sistemas de força de vendas, internet home 
banking , broadcast de informações de bolsas de valores ou de mercado¬ 
rias, sistemas de alerta etc. 

□ Cloud computing. computação na nuvem é uma inovaçáo para a 
infraestrutura de TI. 

A tecnologia da informação pode auxiliar também no aprimoramento de 
processos de negócio, mudando a forma como o processo é conduzido, crian¬ 
do diferenciais ou reduzindo o custo. 

Por exemplo, em um processo de aprovação de crédito ou estabelecimento 
de limites de créditos, sistemas especialistas de credit score ou de “comporta¬ 
mento de crédito”, ou mesmo o cadastro positivo (de bons pagadores), podem 
tornar mais ágil a concessão (ou negaçáo) de uma solicitação de empréstimo 
de um cliente, além de reduzir o custo da operaçáo de crédito. 
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Projetos de inovação podem requerer ambientes de desenvolvimento de 
projetos diferenciados, sem pressão por prazos rígidos, pois há muita pesquisa, 
avaliação se a tecnologia de fato funciona, visitas a fornecedores e a empresas 
que já estão estudando o tema, participação em congressos, desenvolvimento 
de projetos piloto e protótipos. 

Dependendo do tipo de negócio, há testes extensivos para garantir total 
confiabilidade da solução de forma a eliminar riscos para o negócio. 

Portanto, qualquer projeto que tenha as características descritas aqui pode 
ser enquadrado como projeto de inovação. 


3.4.3 O RELACIONAMENTO COM OS USUÁRIOS E/OU CLIENTES 

O modelo de relacionamento refere-se à forma como o cliente solicita o 
serviço, em termos de quem solicita o serviço, como as prioridades são estabe¬ 
lecidas, como os serviços são avaliados, quais os canais de comunicação, como 
as responsabilidades são atribuídas em projetos etc. 

No relacionamento com os usuários e/ou clientes, o que geralmente se 
observa na prática pode ser ilustrado nos seguintes exemplos: 

□ Vários usuários de uma mesma área solicitam serviços para Processos 
e Sistemas, sem uma ordem de prioridade. 

□ Não há critérios de priorização das demandas por parte dos usuários. 

□ Não há padrões de solicitações de serviços. 

□ Os usuários desconhecem o que pode e o que não pode ser solicitado 
e o que pode e o que não pode ser usado. 

□ Não há regras sobre o envolvimento dos usuários nos projetos de TI. 

□ Os usuários geralmente desconhecem os custos dos serviços de TI. 

□ O usuário não sabe quais são os níveis de serviço estipulados por 
TI. 

□ Não há um plano de atendimento claro para as demandas ou serviços 
obrigatórios e que afetam os usuários. 

□ Os usuários desconhecem os princípios de TI etc. 

Na realidade, para muitos usuários, a área de TI é uma “caixa preta” e rea¬ 
liza serviços de qualidade duvidosa. 
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No contexto da Governança de TI, deve-se estabelecer um “modelo de re¬ 
lacionamento” com o usuário, visando garantir a qualidade da prestação de 
serviços. 

Algumas premissas desse modelo são: 

□ Os usuários precisam saber quais serviços de TI estão disponíveis e 
quais não estão. 

□ As demandas de manutenções emergenciais devem ser atendidas sem¬ 
pre através da Central de Serviços (como ponto único de contato), ou 
seja, não pode haver outros canais além da Central de Serviços. 

□ As demandas por projetos e por manutenções programadas devem 
ser encaminhadas, considerando critérios de priorizaçáo usados para 
a gestão do Portfólio de TI. 

□ As demandas por projetos e por manutenções programadas devem ser 
um subconjunto do Portfólio de TI. 

□ O atendimento a demandas por projetos e por manutenções pode 
ser priorizado ao longo do tempo, estimulando a realização de Planos 
de Atendimento trimestrais (de preferência, revistos mensalmente) 
móveis, como, por exemplo, de janeiro a março, fevereiro a abril, e 
assim sucessivamente. 

□ ATI somente irá atender a demandas que estão consideradas no Port¬ 
fólio de TI. Caso ocorram demandas não previstas, a TI, juntamente 
com o usuário, deverá rever o Portfólio e as demais demandas já pro¬ 
gramadas, visando acomodar a capacidade de atendimento. 

□ É recomendável que haja um elo único entre os usuários e a TI no 
que diz respeito à solicitação de projetos e manutenções programadas. 
Algumas empresas criaram o gerente de relacionamento “na casa” do 
usuário, que tem como principal responsabilidade realizar a definição 
preliminar dos requisitos do serviço e das prioridades das demandas. 
Esse papel é desempenhado por um profissional com conhecimento 
do negócio e da tecnologia. 

□ Considerando a melhoria contínua dos serviços, é importante que a 
TI e os usuários estabeleçam os Acordos de Níveis de Serviço e que 
estes sejam avaliados periodicamente, de forma conjunta, quanto ao 
seu desempenho. 
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□ A TI e os usuários devem avaliar, periodicamente, a eficácia do rela¬ 
cionamento e propor melhorias no processo. 

□ O usuário deve ter um canal direto com a TI para realizar sugestões 
de melhoria e também reclamações. No modelo de Governança de 
TI elaborado, o Escritório do CIO pode também ter um papel de 
ombudsman ou ouvidoria, de forma que essas informações cheguem 
ao CIO e possam ser efetivamente tratadas. 

□ Os usuários devem ser avisados, sempre com antecedência, sobre 
eventos de manutenção da rede e de recursos da infraestrutura, ou 
serviços programados de instalação de novas versões de softwares ou 
outros dispositivos. 

□ Os usuários devem ter facilidade de acesso às informações sobre o 
andamento das suas demandas de qualquer natureza. 

□ Os usuários precisam estar cientes dos processos de gestão de 
mudanças. 

Alguns dos instrumentos apresentados pelo modelo de Governança de TI e 
que sáo críticos para o modelo de relacionamento com os usuários sáo: 

□ O Catálogo de Serviços de TI. 

□ Os Acordos de Níveis de Serviço. 

□ O Portfólio de TI. 

□ As ações de endomarketing por parte de TI. 

□ A Central de Serviços. 

□ Revisões conjuntas de desempenho e de melhoria. 

□ O gerente de relacionamento do usuário. 

□ Processo de solicitação de projetos e manutenções. 

□ Regras corporativas quanto ao gerenciamento de projetos e envolvi¬ 
mento dos usuários. 

□ Processo de transferência de preço aos usuários. 

□ Canais de sugestões e reclamações. 

□ Procedimentos de homologação de sistemas. 

□ Estrutura de serviços de TI para os usuários. 

Essa abordagem de relacionamento procura reduzir substancialmente o 
desgaste que muitas organizações de TI sofrem com os seus usuários. 
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3.4.4 O RELACIONAMENTO COM OS FORNECEDORES 

Da mesma forma que o modelo de relacionamento com os clientes, o mo¬ 
delo de relacionamento com os fornecedores é dirigido pela estratégia de sour¬ 
cing , pelos processos de TI relativos à parte terceirizada e pelo Portfólio de TL 
O desenvolvimento e a implantação de um modelo de sourcing é o trabalho 
de tornar a estratégia realidade. 

No relacionamento com os fornecedores, alguns problemas que podemos 
encontrar no dia a dia das empresas que fazem terceirização estão exemplifi¬ 
cados adiante: 

□ Não está claro o que pode e o que não pode ser terceirizado. 

□ Não estão claros os acordos de níveis operacionais e os contratos de 
apoio. 

□ Não há processos de contratação consistentes, considerando a elabo¬ 
ração de Requests for Information (RFI), Requests for Proposal (RFP), 
visitas a clientes dos fornecedores etc. 

□ Geralmente, não há um plano para a transição clara dos serviços da 
área de TI para os terceiros. 

□ Não estão claros quais processos e padrões de TI devem ser aplicados, 
se os do fornecedor ou os da empresa. 

□ Não estão claros quais os limites de cada um (da empresa terceirizada 
e da área de TI). 

□ Não há um processo para a gestão do desempenho dos fornecedores. 

□ Não há um processo consistente de gestão dos acordos de níveis ope¬ 
racionais e dos contratos de apoio. 

□ Não há um processo de revisão conjunta e da melhoria da operação. 

□ Não estão claras, no âmbito da operação do sourcing , quais as respon¬ 
sabilidades da empresa contratante. 

□ Raramente há auditorias de terceira parte na operação de sourcing , 
estejam elas dentro de casa ou nas instalações do fornecedor. 

□ Raramente os benefícios apregoados com a terceirização são medidos 
de fato. 

□ Raramente também há processos de transferência de serviços 
( band-over ), no caso da substituição do prestador de serviços. 
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No contexto da Governança de TI, deve-se estabelecer um modelo 
de relacionamento com fornecedores de serviços, derivado da estratégia 
de sourcing estabelecida pelo processo de planejamento da tecnologia da 
informação. 

As premissas desse modelo são: 

□ Para decidir sobre o que terceirizar, deve-se desenvolver um Business 
Case, refletindo os benefícios para a empresa em termos de custo total 
e apoio efetivo para o negócio. 

□ Os serviços a serem terceirizados devem ser identificados conforme o 
benefício esperado e de acordo com o Portfólio de TI. 

□ As RFIs e RFPs são instrumentos de democratização da disputa, para 
que candidatos possam colocar suas propostas para a empresa (isso 
inclusive melhora a imagem da empresa entre os fornecedores). 

□ Os acordos de nível operacional e os contratos de apoio devem 
ser estabelecidos, considerando o desempenho requerido para o 
negócio. 

□ Os processos e padrões a serem usados para a prestação dos serviços 
devem ser estabelecidos e colocados em contrato. 

□ Um plano de transição deve ser previsto, visando a redução do 
risco operacional da empresa durante a absorção dos serviços pelo 
terceiro. 

□ Um modelo operacional de serviços sobre como solicitar, receber e 
aceitar os serviços e produtos também deve ser elaborado conforme 
os padrões e procedimentos aprovados por ambas as partes. 

□ Neste modelo, também devem estar explícitas quais informações 
de desempenho da operação e dos acordos de níveis operacionais 
e contratos de apoio estarão disponíveis, em que meio, periodici¬ 
dade etc. 

□ A área de TI deve ter um administrador do contrato de terceirização, 
responsável por gerenciar o desempenho do fornecedor e os respec¬ 
tivos acordos, assim como por identificar os pontos de melhoria na 
operação. 

□ Da mesma forma que há canais para o relacionamento entre os 
usuários e a área de TI, também deverá haver canais de relacio¬ 
namento entre a área de TI ou demandante de serviços para o 
terceiro. 
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□ A empresa deve contratar periodicamente e executar auditorias de 
terceira parte sobre a operação de sourcing como um todo. 

□ O administrador do sourcing por parte da empresa e o representante 
da empresa prestadora de serviços devem manter reuniões periódicas 
para a gestão da melhoria da operação. 

□ A empresa contratante deve avaliar e implantar adequações internas 
nos seus processos operacionais e de gestão de TI, visando permitir 
que a operação de sourcing funcione a contento. 

□ Todos os requisitos de segurança da informação devem estar claros para a 
operação de sourcing e ser auditados quanto ao seu cumprimento. 

□ Devem ser estabelecidos regras e processos claros, formalizados em 
contrato, no caso da necessidade de substituir o prestador de serviços. 

□ Os serviços terceirizados e todas as demandas previstas para serem 
executadas pela empresa de prestação de serviços devem estar clara¬ 
mente identificados e priorizados no Portfólio de TI. 

□ A operação deve contar com um Plano de Contingência, para o caso 
de ocorrer algum risco substancial à operação. 

□ O modelo deve estabelecer penalidades por um desempenho abaixo 
dos acordos de níveis de serviço e bônus por um desempenho superior. 

Os instrumentos e ativos críticos para o modelo de relacionamento com os 
fornecedores são: 

□ O processo documentado de contratação. 

□ O contrato de serviços de sourcing. 

□ Plano de contingência dos serviços. 

□ Plano de transferência dos serviços (para o fornecedor e do fornecedor). 

□ Requisitos de segurança da informação. 

□ O Catálogo de Serviços de TI. 

□ Os acordos de nível operacional e contratos de apoio. 

□ O Portfólio de TI. 

□ O Service desk para atendimento aos fornecedores. 

□ Revisões conjuntas de desempenho e de melhoria. 

□ O administrador do sourcing. 

□ O representante da operação por parte do fornecedor ou prestador 
de serviços. 
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□ O modelo documentado da operação. 

□ Processos e padrões documentados e acordados para a gestão e a ope¬ 
ração da prestação dos serviços contratados. 

□ Sistemas de informação de apoio à operação de sourcing. 

Cohen & Young (2006) sugerem a implantação de mecanismos para o 
gerenciamento do que chamam de multisourcing, ou seja, vários sourcings com 
fornecedores distintos prestando serviços distintos. 

Neste caso, propõem três papéis básicos em uma “gestão de multisourcing : 

□ Gerente de relacionamento , responsável pelo desenvolvimento dos 
requisitos dos serviços, priorização, gerenciamento de pendências e 
escalonamento de problemas, monitora o desempenho e os relacio¬ 
namentos e age como um gerente de conta, fazendo a ligação entre os 
fornecedores de serviços e as unidades de negócio. 

□ Gerente do desempenho , responsável por monitorar a operação, a 
integração dos serviços, a gestão de incidentes e a gestão do desem¬ 
penho, inclusive os acordos de níveis operacionais e contratos de 
apoio. 

□ Gerente de contratos , responsável pela gestão de contratos, termos e 
condições, projetos e propostas, e pelo cumprimento dos contratos 
e cronogramas. 

Essas autoras propõem ainda que seja criado um “Escritório de Gestão do 
Multisourcing , com os seguintes processos: 

□ Gestão de programas. 

□ Gestão do desempenho. 

□ Gestão da estratégia. 

□ Gestão da demanda. 

□ Gestão dos serviços. 

□ Gestão financeira do multisourcing. 

□ Gestão dos recursos humanos. 

□ Gestão do relacionamento. 

□ Gestão legal ou jurídica de contratos. 
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Como sempre, o leitor deve interpretar os arcabouços teóricos e casos dis¬ 
poníveis e fazer a sua escolha conforme as condições financeiras, culturais 
e o nível de maturidade de sourcing de sua empresa (vide no Capítulo 11a 
discussão sobre modelos de sourcing para TI). 


3.5 Gerenciamento de recursos 

Função típica de Governança de TI, o gerenciamento de recursos tem por 
objetivo assegurar que recursos necessários para projetos, serviços e inovações 
estejam presentes. 

Para tanto, precisa supervisionar e avaliar os investimentos e o uso de apli¬ 
cação dos recursos, de forma que as necessidades do negócio atendidas por 
projetos, serviços e inovações estejam presentes no Portfólio de TI. 

O gerenciamento de recursos é o foco do processo EDM04 - Assegurar a 
otimização dos recursos do CobiT. 

Este processo tem uma área de interseção com o gerenciamento do portfó¬ 
lio de TI em sua definição dada pelo CobiT (Processo APO05 - Gerenciar 
o portfólio), que é o monitoramento dos investimentos e seus resultados, 
frente aos requisitos e restrições de recursos. 

Podemos considerá-lo como um componente complementar ao gerencia¬ 
mento do Portfólio de TI. 


3.6 A GESTÃO DO DESEMPENHO 

No modelo proposto, o componente Gestão do Desempenho trata basica¬ 
mente de dois conjuntos de medições e indicadores: 

□ Resultados da TI, que compreendem medições e indicadores para: 
execução e gerenciamento de processos e serviços de TI, gerencia¬ 
mento de níveis de serviços, gerenciamento da estratégia e gerencia¬ 
mento de projetos. 

□ Resultados para o negócio, que representam o impacto dos resulta¬ 
dos da TI em termos de agregação de valor para o negócio. 
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Na literatura, de uma forma geral, a gestão do desempenho abrange a 
constituição de um sistema de gerenciamento do desempenho que com¬ 
preende a definição de objetivos de desempenho, a criação dos indicadores 
e acompanha a sua implantação, o monitoramento, a tomada de deci¬ 
são em função dos resultados desses objetivos e as ações consequentes de 
melhoria. 

Toda ação da TI, seja fruto dos seus planos, da sua prestação de serviços e 
desenvolvimento de projetos somente pode ser gerenciada se tiver medições 
e indicadores, conforme a máxima: “você não gerencia o que você não con¬ 
segue medir”. 

Com medições e indicadores você consegue: 

□ Estabelecer metas de melhoria para processos e serviços . “A medição é 
a primeira etapa que leva ao controle e, eventualmente, à melhoria de 
um processo. Se você não consegue medir nada, você não consegue 
entender o processo. Se você não entender o processo, você não o 
controla. Se você não controla o processo, você não pode melhorá-lo” 
[Harrington (2011)]. 

□ Saber quão longe ou perto está de suas metas ou dos níveis de ser¬ 

viços . “Nada é bom ou ruim, mas somente através de comparação” 
[Fuller (1892)]. 

□ Identificar as causas de variações no desempenho de processos e servi¬ 

ços visando tomar ações corretivas ou preventivas a tempo. 

□ Gerenciar um projeto de TL 

□ Comunicar o seu desempenho para a administração . 

□ Garantir o desempenho das funções gerenciais em TI, inclusive Go¬ 
vernança de TI. 

□ Garantir que os riscos de TI para o negócio esteiam sendo gerenciados. 

□ Garantir que a área de TI esteia conforme com os regulamentos ex¬ 

ternos e internos . 

□ Verificar tendências de forma que possa tomar ações preventivas . 

□ Verificar se as melhorias ou correções executadas atingiram, de fato, 

seus objetivos . 

□ Verificar se a TI está agregando valor para o negócio . 

□ Gerenciar com base em fatos e dados , melhorando avaliações e as 
tomadas de decisão. 
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Conforme Edward Deming (2000), um dos pais da qualidade: “Em Deus 
acredito; quanto ao resto, tudo são dados”. 

A gestão do desempenho, para ser perene, requer o desenvolvimento e a 
implantação de um sistema de gerenciamento de desempenho considerando: 

□ Um processo de medição e análise. 

□ Um método para a criação de indicadores. 

□ Um projeto para a sua implantação. 

□ Comunicação eficiente. 

□ Ética no trato com os resultados. 

De acordo com Will Kaydos (1998), um bom sistema de gerenciamento 
de desempenho mantém todos de forma honesta, pois não há como esconder 
os resultados, sendo que, quando o sistema se torna visível, pode fazer algu¬ 
mas pessoas se sentirem desconfortáveis, mas se a liderança da organização 
mantém o tom correto, o medo é rapidamente substituído por uma comuni¬ 
cação mais aberta e honesta, o que é um impacto positivo no relacionamento 
entre os executivos e seus subordinados. 


3.6.1 Medições dos resultados da TI 

Os resultados da TI são as medições derivadas de toda a prestação de ser¬ 
viços em termos de entrega de projetos e serviços e do atendimento a planos 
estratégicos e táticos. 

Os resultados da TI podem ser avaliados através: 

□ da execução e do gerenciamento de processos e serviços de TI; 

□ do gerenciamento dos níveis de serviços; 

□ do gerenciamento da estratégia de TI (BSC); 

□ do gerenciamento de projetos de TI; 

□ do gerenciamento do portfólio de TI. 
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3.6.1.1 Medições para o gerenciamento dos processos e serviços 

O modelo CobiT [ISACA (2012b)] é muito útil quando estamos tratando 
das medições para o gerenciamento dos processos e serviços. Para esse mode¬ 
lo, as metas e métricas sáo definidos em três níveis: 

□ Metas corporativas genéricas , que descrevem a estratégia de negócio 
da empresa (sáo dezessete metas nesta categoria). 

□ Metas relacionadas à TI , cuja influência nas metas corporativas ge¬ 
néricas é considerada primária ou secundária, e que definem o que 
os negócios esperam de TI (sáo também dezessete as metas nesta 
categoria). 

□ Metas específicas para cada processo 20 , que definem o que os pro¬ 
cessos de TI precisam entregar para apoiar as metas relacionadas 
a TI. 

As metas corporativas e as metas relacionadas a TI estão distribuídas entre 
as quatro perspectivas do Balanced Scorecard ; para cada uma dessas metas, sáo 
sugeridas métricas para avaliar o seu atingimento. 

De acordo com esse modelo, existe uma cadeia de relacionamentos entre 
as metas corporativas, as metas relacionadas a TI e as metas de cada processo 
(habilitador). 

A Figura 3.38 representa esta cadeia de relacionamentos, na forma do sis¬ 
tema de metas em cascata 21 proposto pelo CobiT. 


20 A versão 5 do CobiT trouxe o conceito de Habilitador . que significa um aspecto ou elemento que 
possui grande influência no sucesso da governança e do gerenciamento da TI. “ Processos ” são apenas 
uma das categorias de habilitadores. São também categorias de habilitadores “ Principios. políticas 
e estruturas ”. " Estruturas organizacionais ”. Cultura, ética e comportamento ”. “ Informação ". “ Serviços, 
infraestrutura e aplicacões ”e “Pessoas, habilidades e competências”. Cada habilitador é descrito em 
termos de suas partes interessadas, de suas metas, de seu ciclo de vida e de boas práticas a ele 
aplicáveis. 

21 Esta figura aparece novamente no Capítulo 6 deste livro, dentro da descrição resumida do framework 
do CobiT. 
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Motivadores das Partes Interessadas 

(mudanças na estratégia, ambiente de negócios, regulamentos, 
novas tecnologias) 


influenciam 


* 


Necessidades das Partes Interessadas 

(benefícios realizados, riscos otimizados, recursos otimizados) 

^ 


São 

desdobradas em. 


► 


Utilizando 
o BSC 


Metas Corporativas 


São 

desdobradas em 


> 


Criando o 
BSC de TI 


Metas Relacionadas à TI 


São 

desdobradas em 


Cultura, Ética, 
Comportamento ^ 

Estruturas 
Organizacionais ^ 



Serviços, 
Infraestrutura 
e Aplicações 

Pessoas, 

^ Habilidades e 
' Competências 


Princípios, 
^ Políticas e 


I V 

Processos Informação 

Figura 3.38 - 0 Sistema de metas em cascata do CobiT Adaptado de ISACA (2012a) 


Modelos 


O CobiT trabalha com dois tipos de indicadores: as medidas de resultados 
(que indicam se os resultados foram alcançados, também conhecidos como 
lag indicators ) e as medidas de índice de desempenho (que indicam se os 
objetivos poderão ser alcançados, também conhecidos como lead indicators). 
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Lembramos ao leitor que os processos e serviços que devem ser mensu¬ 
rados sáo aqueles considerados críticos, tendo em vista o alinhamento es¬ 
tratégico. Isso significa dizer que o seu modelo de governança não necessita 
abranger, num primeiro momento, todos os 37 processos de TI preconiza¬ 
dos pelo CobiT (o modelo CobiT é detalhado mais adiante, no Capítulo 
6 deste livro). 

Conforme vimos pelo modelo de medição do CobiT, cada processo já 
tem definidas suas metas específicas , suas metas relacionadas à TI e suas 
metas corporativas , assim como suas respectivas métricas . Desta forma, você 
pode escolher a métrica mais apropriada para compor o seu dashboard de 
gestão de TI e também de Governança de TI (no item 3.6.3, exploraremos 
as diferentes visões para a gestão e a Governança de TI visando a construção 
de dasbboards). 

A Tabela 3.13 apresenta algumas métricas de processos propostas pelo 
CobiT. Lembramos também que este jramework tem, em seus apêndices, ta¬ 
belas que mostram o relacionamento entre metas corporativas e metas rela¬ 
cionadas àTI e, na descrição de cada processo, a relação entre as suas metas e 
as metas relacionadas a TL Dessa forma, você pode vincular as metas corpo¬ 
rativas capturadas na fase de alinhamento estratégico com os processos mais 
importantes. 



Meta 

Corporativa 

Meta 

Relacionada 

àTI 

Meta do Processo 
(habilitador) 

PROCESSO: APO02 - Gerenciar a estratégia 

Objetivos 

Demonstração do valor dos 
investimentos de negócio às 
partes interessadas 

Alinhamento entre TI e a 
estratégia do negócio 

Todos os aspectos da 
estratégia de TI estão 
alinhados à estratégia 
corporativa 

Métricas 

% dos investimentos onde 
a entrega de valor atingiu 
as expectativas das partes 
interessadas 

% de objetivos estratégicos 
de TI que suportam 
objetivos estratégicos do 
negócio 

% de objetivos de TI no 
plano de TI que sustentam a 
estratégia corporativa 
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Meta 

Corporativa 

Meta 

Relacionada 

à TI 

Meta do Processo 
(habilitador) 

PROCESSO: BAI06 - Gerenciar mudanças 

Objetivos 

Respostas ágeis a um 
ambiente de negócios 
dinâmico 

Entrega dos serviços de TI 
de forma alinhada com os 
requisitos do negócio 

Mudanças autorizadas são 
executadas em tempo hábil 
e com quantidade mínima de 
erros 

Métricas 

Tempo médio em que 
os objetivos corporativos 
estratégicos se convertem 
em iniciativas acordadas e 
aprovadas 

% de partes interessadas 
do negócio satisfeitas com 
a entrega dos níveis de 
serviço acordados 

Redução do tempo e do 
esforço necessários para a 
execução de mudanças 

PROCESSO: DSS04 - Gerenciar a continuidade 

Objetivos 

Disponibilidade e continuidade 
dos serviços de negócio 

Disponibilidade de 
informação útil e confiável 
para a tomada de decisões 

Informações críticas para o 
negócio estão disponíveis 
para a empresa em 
conformidade com níveis de 
serviço mínimos requeridos 

Métricas 

Quantidade de horas perdidas 
pelos usuários por mês devido 
a interrupções não planejadas 
nos serviços 

Quantidade de incidentes 
em processos críticos 
de negócio causados 
por indisponibilidade de 
infomações 

% de restaurações de 
backups ou cópias em mídias 
alternativas, bem-sucedidas e 
realizadas em tempo hábil 


Tabela 3.13 - Métricas de processo 


Outra medição importante para as atividades de Governança de TI é a ma¬ 
turidade ou a capacidade dos processos. O CobiT, em sua versão 5, preconiza 
um modelo de capacidade com seis níveis: 

□ Incompleto: onde o processo não está implementado ou não atinge 
o seu propósito. 

□ Executado: onde o processo atinge seu propósito. 

□ Gerenciado: onde os produtos do processo são estabelecidos, contro¬ 
lados e mantidos apropriadamente. 

□ Estabelecido: onde o processo utiliza um processo definido e é capaz 
de atingir seus resultados esperados. 

□ Previsível: onde o processo opera dentro de limites definidos para 
atingir seus resultados esperados. 

□ Em otimização: onde o processo é continuamente melhorado para 
atender aos objetivos de negócio atuais e futuros mais relevantes. 
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Modelos de capacidade sáo bastante flexíveis, pois permitem a avaliação 
da evolução individual de cada processo, independentemente de todos os 
demais processos. Outros modelos (tais como CMMI, MPS-br etc., e mes¬ 
mo o CobiT em suas versões anteriores) propõem modelos de maturidade, 
onde são estabelecidos níveis de maturidade relacionados à evolução de um 
conjunto de processos (ou seja, a evolução de um grupo de processos até um 
certo grau de capacidade confere à organização um grau de maturidade). 

A avaliação periódica da capacidade ou da maturidade do processo pode 
indicar melhorias cuja implantação no processo seja necessária, considerando 
o risco e o atendimento aos objetivos do negócio. 

O estabelecimento de objetivos para os processos de TI e dos respectivos 
níveis de maturidade ou capacidade (desejados ou necessários), podem fazer 
parte da estratégia de TI derivada do BSC. 


3.6.1.2 Medições para o gerenciamento dos níveis de serviços 

Outro conjunto de medições que, aos olhos dos executivos de negócio, são 
extremamente importantes são os acordos de níveis de serviços. 

Alguns dos níveis de serviços típicos aos usuários são (a lista não se esgota 
aqui): 

□ Disponibilidade de serviços como e-mail. 

□ Disponibilidade de aplicações corporativas. 

□ Disponibilidade de aplicações na Internet. 

□ Tempos de resolução de incidentes. 

□ Tempos de atendimento de chamados de serviços. 

□ Tempos de recuperação de serviços. 

□ Taxa de entrega de projetos no prazo. 

□ Tempos de parada ( downtime ). 

□ Tempos médios de resposta para a resolução de incidentes. 

□ Tempos de reparação. 

□ Eficiência do primeiro nível de suporte. 

□ Eficiência do segundo nível de suporte. 

□ % de backouts 22 relacionados com as mudanças. 


22 Backouts são mudanças que retornam da produção por problemas de qualidade (falhas ou defeitos). 
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□ Taxa de cumprimento do scbeduling de processamento batch. 

□ Taxa de cumprimento do scbeduling de impressão. 

□ Taxa de cumprimento do scbeduling de backup. 

□ Tempo de recuperação e restauração de dados. 

□ Taxa de cobertura da manutenção preventiva sobre os componentes 
da infraestrutura. 

□ Tempos médios de resposta das aplicações. 

□ Quantidade de testes dos planos de continuidade de serviços. 

□ Percentual de cobertura da conscientização para a segurança 
da informação dos recursos humanos (terceiros, fornecedores, 
parceiros). 

□ Taxa de defeitos pós -release do software. 

O valor numérico do nível do serviço é um padrão a ser mantido. No dia a 
dia das operações de serviços torna-se o elemento que fornece o controle mais 
operacional. 

O nível de serviço não é um objetivo ou meta da TL Entretanto, podemos 

ter como meta passar de um nível inferior para outro superior e expressar isto 

no plano de tecnologia ou no BSC. 

O nível de serviço é um compromisso que, uma vez assumido, tem que ser 
proporcionado imediatamente para o cliente. 

A fonte dos níveis de serviços a serem gerenciados é o catálogo de serviços 
definido na estratégia de serviços. 


3.6.1.3 Medições para o gerenciamento da estratégia (BSC) 

As medições para o gerenciamento da estratégia constituem-se nos indica¬ 
dores de resultado que demonstram o atendimento aos objetivos da estratégia 
e aos indicadores de desempenho associados, expressos no IT BSC (vide Fi¬ 
gura 3.34, mostrada anteriormente). 

Geralmente, a estratégia foca em objetivos estratégicos, como mostrado no 
IT BSC e reproduzido parcialmente a seguir. 

□ Entregar projetos e serviços no prazo. 

□ Realizar economias de escala. 

□ Padronizar arquiteturas. 
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□ Otimizar processos de TI. 

□ Gerenciar a qualidade dos serviços. 

□ Fornecer serviços com qualidade a custos competitivos. 

□ Melhorar a produtividade das unidades de negócio. 

□ Fornecer o suporte efetivo aos usuários. 

□ Propor e entregar soluções capacitadoras. 

□ Entender a aplicação de tecnologias emergentes. 

□ Entender a estratégia das unidades de negócio. 

□ Atrair e reter pessoas com habilidades chaves. 

□ Desenvolver carreiras. 

□ Promover cultura de inovação etc. 

Para cada objetivo estratégico, podem ser definidos indicadores de resulta¬ 
dos com os seus indicadores de desempenho. 

As medições da estratégia são empregadas para o gerenciamento da estra¬ 
tégia. No exemplo dado na Tabela 3.14, para atingir um aumento da entrega 
de prazos, são necessárias três iniciativas. Repoduzimos a seguir esta tabela de 
forma parcial. 

O objetivo de entregar no prazo, por exemplo, 80% dos projetos, so¬ 
mente poderá ser observado se as metas de resultados das iniciativas forem 
atingidas. 


Objetivo 

estratégico 

Iniciativas 

Meta de 

resultado 

Meta de 
desempenho 


Implantar processo 
de estimativa 

50% dos projetos críticos 
empregaram o novo método de 
estimativa até dezembro de 2013. 

25% dos projetos com o novo 
processo até junho de 2014. 

Entregar no 
prazo 

Implantar processo 
de requisitos 

80% dos projetos com processo 
de gestão de requisitos até 
dezembro de 2013. 

40% dos projetos com processo 
de gestão de requisitos até 
junho de 2014; 

60% dos projetos até setembro 
de 2014. 


Implantar processo 
de gerenciamento de 
projetos 

100% dos projetos usam o 
processo de gestão de projetos 
até dezembro de 2013. 

30% dos projetos até março de 
2014; 

60% até junho de 2014. 


Tabela 3.14 - Metas de resultado e de desempenho 
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3.6.1.4 Medições para o gerenciamento de projetos 

As medições para o gerenciamento de projetos sáo bem definidas pelas 
publicações do Project Management Institute : 

□ Curva S, que mostra o progresso contra o tempo, refletindo a quanti¬ 
dade de trabalho até a data. A Figura 3.39 mostra uma curva S. 



E * i t - I " o g-D 

-♦-Planejado -«-Entregue -*-IAC 


Figura 3.39 - Exemplo de curva S 


□ Indicadores de EVM - Earned Value Management. A Tabela 3.15 
mostra os principais indicadores de EVM. 


Questões de gerenciamento de projetos 

Medições de desempenho 

Como estamos usando o tempo? 

Análise do cronograma e previsão 

Estamos atrasados ou adiantados? 

Variância do cronograma (Schedule variance ) 

Estamos usando o tempo de forma eficiente? 

índice de desempenho do cronograma (Schedule 
performance index) 

Quando, provavelmente, terminaremos o trabalho? 

Estimativa de prazo ao témino (Time estimate at 
completion) 
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Questões de gerenciamento de projetos 

Medições de desempenho 

Como estamos lidando com o custo? 

Análise do custo e previsão 

Estamos abaixo ou acima do orçamento? 

Variância do custo (Cosí variance) 

Estamos usando os recursos de forma eficiente? 

índice de desempenho do custo (Cost performance 

Índex ) 

Como devemos, de forma eficiente, usar os 
recursos restantes? 

índice de desempenho para completar ( Estimate to 
complete performance index) 

Quanto o projeto provavelmente vai custar? 

Estimativa ao término (Estimate at comptetion) 

Estaremos abaixo ou acima do orçamento? 

Variância ao término (Variance at compietiorí) 

Quanto vai custar o trabalho restante? 

Estimativa ao término (Estimate at compietiorí] 


Tabela 3.15 - Medições para o gerenciamento de projetos 


Outros indicadores para o gerenciamento de projetos sáo: de qualidade 
(não conformidades sobre itens avaliados), riscos (quantidade de riscos, im¬ 
pactos e probabilidades), quantidade de mudanças etc. 


3.6.1.5 Medições para o gerenciamento do portfólio de TI 

As medições para o gerenciamento do portfólio de TI têm por objetivo ve¬ 
rificar o balanceamento de recursos entre as categorias de projetos/programas, 
serviços e ativos. 

Alguns tipos de medições sugeridas sáo: 

□ Distribuição dos recursos orçamentários pelas categorias de pro¬ 
jetos, serviços e ativos do portfólio: neste caso podemos verificar a 
distribuição orçamentária balanceada em função das diretrizes estra¬ 
tégicas da TI e da organização. 

□ Distribuição dos recursos orçamentários conforme a finalidade 
do investimento (se é para a estratégia da empresa, nova estratégia, 
fábrica e obrigatórios): neste caso podemos ver se o montante de di¬ 
nheiro está indo para a finalidade correta; por exemplo, supondo que 
a organização está numa fase de transformação e a maior parte do di¬ 
nheiro está alocada para manutenção e atividades obrigatórias. Neste 
caso, temos um problema. 
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□ Estatísticas básicas sobre quantidade de projetos por categoria, 
serviços e ativos: esta volumetria é importante para a TI saber como 
anda a demanda por seus serviços. 

□ Indicadores consolidados sobre a execução dos projetos e servi¬ 
ços: aqui podemos ver por que alguns tipos de projetos e serviços váo 
melhor do que outros. 

□ Estatísticas básicas sobre a distribuição dos projetos, serviços e 
ativos por área funcional da TI: informa a carga e concentração 
de projetos e serviços por área da TI; a questão é se os recursos estão 
alocados de forma equilibrada. 

□ Estatísticas básicas sobre a distribuição dos projetos, serviços e 
ativos por Unidade de Negócio da organização: apoia a TI no sen¬ 
tido de mostrar quanto cada Unidade de Negócio está consumindo 
de recursos da TI. 

□ Distribuição dos recursos orçamentários por Unidade de Negócio, 
em função dos projetos, serviços e ativos: idem à explicação anterior. 

□ Distribuição dos recursos orçamentários por área funcional da 

TI: permite verificar se a distribuição orçamentária está balanceada e 
adequada. 

Indicadores de alinhamento que fornecem informações sobre a relação dos 
projetos realizados fora do portfólio de TI: esses tipos de indicadores são ex¬ 
tremamente importantes, pois mostram quão alinhada está a demanda em 
relação aos objetivos estratégicos do negócio e da organização. Quando mais 
desalinhado, maior será o problema para resolver. 


3.6.2 Medições dos resultados para o negócio 

As medições dos resultados para o negócio são vinculadas à demonstração 
de valor da TI para o negócio, que é um dos grandes problemas de comuni¬ 
cação da TI. 

O valor da TI para o negócio é percebido pelos executivos das unidades de 
negócio da organização quando a TI: 

□ Mantém a disponibilidade das aplicações e sistemas de acordo com as 
necessidades do negócio. 

□ Reduz o risco para o negócio (riscos operacionais e de compliancé). 
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□ Garante a qualidade e consistência dos serviços do ponto de vista do 
negócio. 

□ Entrega projetos e serviços no prazo, com qualidade e dentro da ja¬ 
nela de oportunidade do negócio (isso significa que não adianta en¬ 
tregar no prazo um projeto que deveria ter sido feito há dois anos). 

□ Pode oferecer soluções capacitadoras e diferenciadas para alavancar 
novos negócios, negócios existentes, assim como reduzir custos ope¬ 
racionais de forma proativa. 

Entretanto, temos que vincular tudo isso a ganhos financeiros, o que não 
é uma tarefa fácil. 

Além disso, existe um debate muito grande sobre de quem é a responsa¬ 
bilidade pela elaboração da análise de investimentos, que tem a TI como um 
dos seus componentes. 

Conforme Hunter & Westerman (2009), não existem projetos de TI; na 
realidade, todos os projetos são de negócios. Segundo esses autores, a TI deve 
mudar a linguagem, como mostra a Tabela 3.16. 


Não diga 

Diga 

Solução de ERP 

Transformação da manufatura 

Disponibilidade da rede 

Disponibilidade dos pontos de venda 

Ciclo de vida de desenvolvimento de aplicações 

Ciclo de vida do desenvolvimento do produto 

Construir a infraestrutura de TI 

Suportar o crescimento do negócio 

Instalar o CRM 

Capturar e manter clientes 


Tabela 3.16 - Comunicar o valor da TI 


Em relação a esse debate, nossa posição pode ser entendida pela Tabela 3.17. 


Projeto/Serviço/Solução 

Responsabilidades 

Negócio 

TI 

Projetos de negócio onde a TI é um 
componente essencial. 

0 negócio tem a responsabilidade 
pela análise de investimentos e 
avaliação do resultado obtido. 

TI apoia o negócio para a 
análise de investimentos, mas 
a responsabilidade principal é 
do negócio. 
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Projeto/Serviço/Solução 

Responsabilidades 

Negócio 

TI 

Projetos de novas tecnologias ou novas 
soluções de TI propostas e aceitas pelo 
negócio. 

0 negócio suporta a TI fornecendo 
informações sobre o negócio 
para a TI realizar a análise de 
investimentos. 

A responsabilidade principal 
pela análise de investimentos 
e avaliação de resultados é 
da TI. 

Projetos e soluções específicos de 

TI para a melhoria dos serviços, 
redução de custos operacionais da TI e 
otimização da infraestrutura. 

0 negócio deve fornecer 
parâmetros para a TI poder 
realizar a análise de investimento. 

A TI tem a responsabilidade 
principal pela análise de 
investimentos. 

Disponibilidade dos serviços. 

0 negócio deve fornecer 
parâmetros do negócio para a 

TI poder realizar a análise de 
investimento. 

A TI tem a responsabilidade 
principal pela análise de 
investimentos. 

Risco da TI. 

0 negócio deve fornecer 
parâmetros de perdas se um risco 
interromper as operações. 

A TI, juntamente com a área 
de Gestão de Riscos, analisa 
as perdas para o negócio 
caso ocorrer um risco e pode 
associar investimentos para a 
mitigação dos riscos. 


Tabela 3.17 - Responsabilidades por elaborar análises de investimento 


A seguir, são dados alguns exemplos dos parâmetros e da apuração do re¬ 
torno desses tipos de projetos/serviços/soluções. ATabela 3.18 mostra alguns 
exercícios recomendados para demonstrar o valor da TI para o negócio. 

Todo esse raciocínio deve ser fruto de um Business Case que realize um estudo 
para determinar os benefícios quantitativos e qualitativos de um investimento. 

A sugestão é que se faça o Business Case somente para investimentos rele¬ 
vantes e considerados estratégicos pela organização. 


3.6.3 Implantação de sistema de gerenciamento de 

DESEMPENHO 

3.6.3.1 O processo de medição e análise 

O CMMI [SEI (2010b)] nos ajuda em muito para determinarmos um 
processo de medição e análise. 

A comunicação dos resultados dos indicadores não é realizada somente 
com a captura e a publicação no dashboard. Toda comunicação de resultados 
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requer que a captura seja administrada, que os resultados sejam analisados 
e que as variações nos resultados sejam entendidas e explicadas para então 
serem publicados. 

Além do mais, precisamos ter formas de criar novos indicadores, especifi¬ 
cá-los e definir responsabilidades pela coleta, além de determinar quem pode 
ter acesso, quando as medições vão ser capturadas, que tipo de análise deve ser 
realizada e assim por diante. 

O CMMI, em seu modelo, propõe uma Área de Processo no seu nível 2 de 
maturidade denominada “Mediçáo e Análise”. 


Tipo do Projeto/ 

Serviço / Solução 

Exemplo 

Raciocínio para a 

Criação de Valor 

Projetos de negócio onde a TI é um 
componente essencial 

Implantação de um sistema de 
força de vendas 

No Business Case, temos que 
levantar a situação atual de vendas 
sem o sistema e projetar o aumento 
de receita depois do sistema 
implantado. Essa diferença será a 
entrada no fluxo de caixa. Os gastos 
com a implantação são a saída do 
fluxo de caixa. A taxa de retorno 
deve ser maior do que a taxa SELIC 
estabelecida pelo Conselho Monetário 
Nacional. No fluxo de caixa, deve ser 
demonstrado quando o investimento 
se paga (payback) e quando é o ponto 
onde o montante de entrada de caixa 
é igual à saída (breakeven). 

Projetos de novas tecnologias ou 
novas soluções de TI, propostos e 
aceitos pelo negócio 

Implantação de um processo de 
gerenciamento do conhecimento 

Aqui, temos que levantar perdas 
ocasionadas por perda de 
conhecimento. Exemplo: um 
produto que a organização produzia 
no passado que começa a ser 
demandado novamente, mas para 
o qual, entretanto, a organização 
perdeu as especificações ou fórmulas 
e tem que desenvolver novamente do 
zero. Esse reinvestimento é o valor 
da perda. 

0 ganho será evitar o reinvestimento 
novamente para todos os produtos. 
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Tipo do Projeto/ 

Serviço / Solução 

Exemplo 

Raciocínio para a 

Criação de Valor 

Projetos e soluções específicas de 

TI para a melhoria dos serviços, 
redução de custos operacionais da 
TI e otimização da infraestrutura 

Implantação de um novo 
processo de desenvolvimento 
de software, com o objetivo 
de encurtar o ciclo de 
desenvolvimento 

Neste caso, o encurtamento do ciclo 
de desenvolvimento poderá gerar 
mais caixa, pois os novos produtos/ 
serviços do negócio poderão ter 
seus lançamentos antecipados. 

Se buscarmos dados históricos de 
impossibilidade de antecipação de 
lançamento face a atrasos na entrega, 
poderemos ver o montante de 
dinheiro perdido no passado. 

Disponibilidade dos serviços 

Aumento da disponibilidade 
dos sistemas que apoiam um 
negócio 

Neste caso, se aumentarmos a 
disponibilidade ou proporcionarmos 
a disponibilidade necessária no 
momento em que o negócio precisa, 
podemos auxiliar o negócio a gerar 
mais caixa. Imaginemos um negócio 
onde o final de semana representa 
a maior parte da receita mensal. 

Se a disponibilidade é ruim e 
conseguirmos aumentá-la, estaremos 
ajudando o negócio a gerar mais 
caixa. 

Riscos da TI 

Aqui podemos ter uma série 
de iniciativas com o objetivo de 
reduzir o negócio à exposição 
ao risco (probabilidade e 
impacto de ocorrência) 

Suponha que atualmente a 
exposição ao risco 23 de um 
negócio, considerando todo o ciclo 
do processo, é 100. Se, com as 
iniciativas de TI, conseguirmos 
reduzir a exposição a 50, o ganho 
(entrada de caixa no fluxo de caixa) 
será de 50. É óbvio que as iniciativas 
têm que dar o retorno desejado no 
prazo estipulado. 


Tabela 3.18 - Raciocínio para a comunicação do valor 


Esta Área de Processo tem por objetivo desenvolver e sustentar a capacidade 
de medições que é utilizada para suportar as necessidades de gerenciamento de 
informações. 

A Figura 3.40 mostra um esquema dessa área de processo, com foco nas 
práticas das metas específicas do modelo 24 : 

23 Exposição ao risco é a probabilidade de perda financeira medida através da probabilidade de ocorrência 
do risco pela perda financeira no caso da ocorrência do risco 

24 As áreas de processo do CM Ml são compostas por metas específicas (que são os processos em si) 
e metas genéricas (que são elementos capacitadores para que o processo possa ser executado). 
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A seguir, fornecemos um extrato dos objetivos das práticas específicas do 
CMMI. 

□ Estabelecer os objetivos da medição: o objetivo da prática é estabe¬ 
lecer e manter os objetivos de medições que sáo derivados das neces¬ 
sidades e dos objetivos de informações identificados. 

A Os objetivos de medições documentam os propósitos para os 
quais as medições e análises sáo feitas, e especificam os tipos de 
ações que podem ser tomadas com base nos resultados das análises 
dos dados. 



Figura 3.40 - Processo de medição e análise Adaptado de: SEI (2010b) 


A As fontes para os objetivos de medições podem ser as necessidades 
técnicas e de gerenciamento do projeto, do produto ou de imple¬ 
mentação do processo. 

A Os objetivos de medições podem ser restringidos pelos processos 
existentes, recursos disponíveis ou outras considerações de medi¬ 
ções. E necessário julgar se o valor dos resultados será proporcio¬ 
nal aos recursos dedicados a este trabalho. 
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A Modificações em necessidades e objetivos de informações iden¬ 
tificados podem, por sua vez, ser indicadas em consequência do 
processo e dos resultados das medições e análises. 

□ Especificar as medições: o objetivo desta prática é especificar medi¬ 
das para tratar os objetivos de medições. 

A Os objetivos de medições sáo refinados em medidas precisas e 
quantificáveis. 

A As medidas podem ser “básicas” ou “derivadas”. Os dados para 
as medidas básicas sáo obtidos através de mediçáo direta. Os 
dados para medidas derivadas provêm de outros dados, nor¬ 
malmente, através da combinação de duas ou mais medidas 
básicas. 

A As medidas derivadas normalmente sáo expressas como razões, 
índices compostos e outras medidas de resumo agregadas. Elas 
sáo, normalmente, mais confiáveis quantitativamente e sua in¬ 
terpretação tem mais sentido que as medidas básicas utilizadas 
para gerá-las. 

□ Especificar procedimentos de coleta e armazenamento de dados: 

o objetivo desta prática é especificar como os dados de medições seráo 
obtidos e armazenados. 

A A especificação explícita de métodos de coleta ajuda a assegurar 
que os dados corretos estáo sendo coletados de forma apropriada. 
Ela também auxilia a esclarecer ainda mais as necessidades de in¬ 
formações e os objetivos das medições. 

A A atençáo apropriada aos procedimentos de armazenagem e re¬ 
cuperação ajuda a assegurar que os dados estaráo disponíveis e 
acessíveis para uso futuro. 

□ Especificar os procedimentos de análise: esta prática tem por 
objetivo especificar como os dados de medições seráo analisados e 
comunicados. 

A Especificar antecipadamente os procedimentos de análise asse¬ 
gura que as análises apropriadas seráo executadas e comunicadas 
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para atender aos objetivos documentados das medições (e, por¬ 
tanto, às necessidades e aos objetivos de informações nos quais 
eles foram baseados). Essa abordagem também garante uma 
conferência para verificar se os dados necessários serão de fato 
coletados. 

□ Coletar dados de medições: esta prática tem por objetivo obter os 
dados de medições especificados. 

A Os dados necessários para a análise sáo obtidos e conferidos quan¬ 
to à sua inteireza e integridade. 

□ Analisar dados das medições: esta prática tem por objetivo analisar 
e interpretar os dados de medições. 

A Os dados de medições sáo analisados conforme planejado, as aná¬ 
lises adicionais sáo conduzidas conforme necessário, os resultados 
sáo revisados com os stakeholders relevantes e revisões necessárias 
para análises futuras sáo anotadas. 

□ Armazenar os dados e os resultados: esta prática tem por objetivo 
gerenciar e armazenar os dados de medições, especificações de medi¬ 
ções e resultados de análises. 

A Armazenar informações relacionadas a medições possibilita o uso 
futuro pontual e eficiente, em termos de custos, dos dados histó¬ 
ricos e resultados. As informações também sáo necessárias para 
fornecer um contexto suficiente para a interpretação dos dados, 
dos critérios de medições e dos resultados das análises. 

A As informações armazenadas normalmente incluem: 

° Planos de medições. 

° Especificações de medidas. 

° Conjuntos de dados que foram coletados. 

° Relatórios de análises e apresentações. 

A As informações armazenadas contêm ou fazem referência às in¬ 
formações necessárias para entender e interpretar as medidas e 
analisá-las com relaçáo à motivação e aplicabilidade (por exem¬ 
plo, especificações de medições usadas em diferentes projetos para 
a comparação entre projetos). 
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A Conjuntos de dados para medidas derivadas normalmente po¬ 
dem ser recalculados e não precisam ser armazenados. Entretan¬ 
to, pode ser apropriado armazenar resumos baseados nas medi¬ 
das derivadas (por exemplo, gráficos, tabelas de resultados ou 
relatórios descritivos). 

A Resultados intermediários das análises náo precisam ser ar¬ 
mazenados separadamente, se puderem ser eficientemente 
reconstruídos. 

□ Comunicar resultados: esta prática tem por objetivo relatar os resul¬ 
tados das atividades de medições e análises para todos os stakebolders 
relevantes. 

A Os resultados do processo de medições e análises sáo comunica¬ 
dos aos stakebolders relevantes, de uma maneira pontual e fácil de 
utilizar, para suportar a tomada de decisões e auxiliar na tomada 
das ações corretivas. 

A Os stakebolders relevantes incluem os usuários pretendidos, patro¬ 
cinadores, analistas e fornecedores de dados. 

Avisamos o leitor que, sem um processo definido para o sistema de geren¬ 
ciamento do desempenho, mesmo mais simplificado do que este aqui descri¬ 
to, qualquer esforço de mediçáo estará fadado ao fracasso. 


3.6.3.2 O método de identificação de indicadores 

Outro componente importante do gerenciamento do desempenho é o mé¬ 
todo para a identificação ou descoberta dos indicadores requeridos. 

Uma boa alternativa metodológica para a criaçáo e manutenção dos indi¬ 
cadores nos é dada pelo método Goal Question Indicators Metbod , desenvol¬ 
vido por Robert Park e colegas do Software Engineering Institute da Carnegie 
Mellon University - vide Park (1996). 

Este método, embora inicialmente tenha sido desenvolvido para atender 
a processos relacionados a software, é consistente para aplicação em outros 
domínios. 
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O método parte de três premissas: 

□ Objetivos de medição são derivados de objetivos de negócio. 

□ Modelos mentais fornecem o contexto e o foco para a medição. 

□ O método traduz metas informais em estruturas de medição executáveis. 

O método é composto por dez etapas: 

□ Identificação dos objetivos do negócio. 

□ Identificação do que se deseja aprender. 

□ Identificação de subobjetivos. 

□ Identificação de entidades e atributos relacionados aos subobjetivos. 

□ Formalização dos objetivos da medição. 

□ Identificação de questões quantificáveis e dos indicadores relacionados. 

□ Identificação de elementos de dados que devem ser coletados para 
construir os indicadores. 

□ Definição das medições a serem usadas em termos operacionais. 

□ Identificação das ações que devem ser tomadas para a implantação 
das medições. 

□ Preparação de um plano para a implantação das medições. 

A Figura 3.41 apresenta o esquema geral do método. 

Outra abordagem que merece ser estudada é a proposta dada pelo “Practi- 
cal Software Measurement” - vide McGarry et al (2002). 

Independentemente de qualquer abordagem, é importante, na criação 
dos indicadores, definir o que chamamos de “metadados dos indicadores”, 
que são todas as informações necessárias sobre o indicador que está sendo 
criado e que podem ser reutilizadas para outros fins (diversos processos e 
projetos). 
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Figura 3.41 - Modelo de processo para selecionar indicadores 
Adaptado de Park (1996) 


A Figura 3.42 apresenta o conteúdo de um conjunto de metadados de in¬ 
dicadores de produtividade do desenvolvimento de software. 
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Metadados de Medições 

• definição 


operacional da 


medição; 

• identificador da 

• regras de coleta e 

medição; 

aramazenamento; 

• nome da medição; 

• responsabilidades; 

• indicadores 

• requisitos de 

relacionados; 

segurança dos 

• elementos de dados; 

dados; 

• fonte dos dados; 

• quando a medição 

• se manual ou 

deve ser gerada; 

automatizada; 

• tamanho da série 

• quando os elementos 

histórica; 

de dados devem estar 

• regras de retenção 

disponíveis; 

dos dados. 


Metadados de 



Indicadores 



• identificador do 


modelo de gestão que 

indicador; 


apoia; 

• nome do indicador; 


timeline do indicador; 

• objetivos de medição 


interpretação dos 

relacionados; 


resultados; 

• medições básicas; 


responsabilidades; 

• indicadores derivados; • 

requisitos de segurança 

• fórmula do indicador; 

dos dados; 

• regra de anualização do • 

verificação de causa e 

resultado do indicador; 

efeito; 

• regras de coleta e 


tamanho da série 

armazenamento; 


histórica; 

• forma de apresentação • 

regras de retenção dos 

do resultado; 


dados. 


Figura 3.42 - Exemplos de metadados de indicadores 25 


Os metadados dos indicadores equivalem à especificação das medições. 


3.6.3.3 O projeto de implantação do sistema de gerenciamento de 
desempenho 

3.6.3.3.1 Características de projetos de gerenciamento de desempenho 

A implantação de um sistema de gerenciamento de desempenho é um 
projeto que irá depender de vários fatores: técnicos, organizacionais, com- 
portamentais e individuais referentes aos gestores. Esses últimos fatores são 
de suma importância, pois, quando se trata de sistemas de informações ge¬ 
renciais, há muita dependência da característica de cada tomador de decisão. 


25 Ponto de função é uma métrica de tamanho do software, de acordo com as funcionalidades 
identificadas do ponto de vista do usuário e conforme as características dos requisitos não funcionais. 
Esta métrica é mantida pelo International Function Point Users Group (www.ifpug.org). 
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Alguns gostam de detalhes e sáo centralizadores, outros gostam de ver a figura 
como um todo, em nível mais elevado. Esse aspecto tem um tremendo impac¬ 
to na forma como desenhamos e comunicamos os resultados. 

Os principais entregáveis deste projeto são: 

□ O processo de medição e análise. 

□ A capacitação de pessoal para a operação do processo e realização de 
análises e comunicação de resultados. 

□ Os metadados de indicadores. 

□ Interfaces com sistemas de monitoramento e controle de TI. 

□ O dashboard de Governança de TI. 

□ O plano de gerenciamento da mudança organizacional. 

Um projeto dessa natureza requer uma estratégia particular, pois mui¬ 
tos indicadores dependem de processos e controles que não existem ainda 
e há, geralmente, grande resistência por parte das áreas de TI em fornecer 
informações, o que requer uma estratégia de gerenciamento da mudança 
organizacional. 

Além do mais, existe a questão da qualidade da informação, que depende 
das definições operacionais de cada medição a ser utilizada para formar o 
dashboard , assim como a questão da viabilidade de obter as medições. Às ve¬ 
zes, o custo de implantar um controle é tão grande que não compensa obter 
a medição. Você irá encontrar situações onde a captura da informação é mais 
viável se obtida de forma manual. 

Outro aspecto importante é que, em determinado momento do projeto, 
deverá ser decidido quem será o canal oficial de comunicação de resultados 
sobre a Governança de TI na área de TI (o mesmo vale se estivermos pensan¬ 
do em construir um dashboard mais abrangente para o gerenciamento da TI). 
A determinação do canal oficial de comunicação serve para evitar duplicidade 
de comunicação e também que informações conflitantes sobre o mesmo re¬ 
sultado possam desvirtuar o processo. 

Portanto, as informações comunicadas por esse canal oficial sáo as que irão 
valer para fins de tomada de decisão. E isso naturalmente dependerá forte¬ 
mente do compromisso do executivo responsável pela área de TI. 

A implantação do dashboard é evolutiva, pois você certamente não con¬ 
seguirá implantar tudo de uma vez só. Então a estratégia mais indicada é 
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começar por um conjunto pequeno de indicadores que, de preferência, sejam 
vitais. Náo adianta também comunicar resultados se não há ação gerencial 
como decorrência, pois o pessoal que fornece as informações irá começar a 
questionar o porquê do esforço de coleta de medições, se ninguém está usan¬ 
do as informações. Assim, a credibilidade da iniciativa começará a ser questio¬ 
nada e poderá ser interrompida. 

Entretanto, mesmo que você já saiba de antemáo de quais indicadores você 
necessita para a Governança de TI, você ainda depende da visáo de quem irá 
receber a informação e tomar decisões com ela. Como falamos no início deste 
capítulo, sistemas de informações gerenciais dependem fortemente das carac¬ 
terísticas individuais dos tomadores de decisáo. 

O ideal é começar através de um protótipo, mostrando quem vai usar a 
informação. Pode até ocorrer mais de um ciclo de prototipação até que os re¬ 
quisitos estejam estabilizados. Faça, porém, um protótipo funcional e esqueça 
o Powerpoint. Empregue, para tanto, ferramentas de BI de fácil utilização. 
Nesse momento você náo pode depender fortemente do pessoal de desenvol¬ 
vimento de sistemas. 


3.6.33.2 As etapas de um projeto de gerenciamento de desempenho 

Em seu trabalho Performance Management Strategies: how to create and 
deploy ejfective metrics (TDWI Best Practices Report), Wayne W. Eckerson 
(2009) propõe a seguinte abordagem para a construção de um dasbboard de 
desempenho: 

□ Antes de iniciar o projeto: 

A Estabelecer a estratégia. 

A Obter patrocínio adequado para o projeto. 

A Definir uma metodologia. 

A Definir equipe e escopo do projeto. 

□ Durante o projeto: 

A Definir requisitos. 

A Priorizar e normalizar (elaborar os metadados dos indicadores). 

A Coletar os dados. 

A Desenvolver o dasbboard. 
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□ Depois do projeto: 

A Fazer propaganda do projeto. 

A Monitorar e revisar os indicadores de desempenho. 

A Governar o processo. 

A Fornecer coaching para gerentes e usuários. 

A jornada para a implantação de um dashboard de TI segue a sequência 
mostrada pela Figura 3.43, considerando uma estratégia evolutiva. 



• Plano do projeto 

• Plano de recursos 

• Plano de comunicação 

• Plano da qualidade 

• Plano de comunicação 

• Seleção da tecnologia 


• Identificação de 
necessidades das partes 
interessadas 

• Elaboração do modelo de 
dashboard objetivo 

• Análise de viabilidade de 
implantação dos 
indicadores 

• Elaboração de protótipos 

• Implantação do processo 
de medição e análise 

• Implantação do 
dashboard (ciclo 1) 

• Planejamento de 
implantação de 
indicadores para o ciclo 
seguinte 

• Implantação de controles 
para os indicadores do 
ciclo seguinte 


• Revisão das 
necessidades das partes 
interessadas 

• Análise de viabilidade de 
implantação de novos 
indicadores 

• Elaboração de protótipos 

• Implantação do 
dashboard (ciclo 2) 

• Planejamento de 
implantação de 
indicadores para o ciclo 
seguinte 

• Implantação de controles 
para os indicadores do 
ciclo seguinte 


• Revisão das 
necessidades das partes 
interessadas 

•Análise de viabilidade de 
implantação de novos 
indicadores 

• Elaboração de protótipos 

• Implantação do 
dashboard (ciclo n) 

• Planejamento de 
implantação de 
indicadores para o ciclo 
seguinte 

• Implantação de controles 
para os indicadores do 
ciclo seguinte 


Figura 3.43 - Etapas de um projeto de dashboard 


3.6.3.33 Características de um bom dashboard 

De acordo com Eckerson (2009), um dashboard de desempenho faz o en¬ 
capsulamento de métricas de desempenho em camadas e por sistemas de co¬ 
municação visual que permite aos usuários mensurar, monitorar e gerenciar 
a eficácia de suas táticas e seu progresso em direção a objetivos estratégicos. 
Um dashboard de desempenho pode consistir de um ou mais dashboards, 
scorecards, relatórios e ferramentas analíticas que processam um conjunto co- 
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mum de dados e métricas. Coletivamente, permitem aos usuários identificar 
problemas e oportunidades, colaborar sobre abordagens, tomar ações e ajustar 
planos e metas, quando necessário. 

Cada dashboard de desempenho emprega um subconjunto de componen¬ 
tes que sáo mostrados em cada nível da arquitetura técnica, com base nas 
métricas e nos objetivos estratégicos que apoia. 

Os dashboards normalmente sáo compostos por: 

□ Estruturas gráficas. 

□ Estruturas de medidores. 

□ Informações complementares (tabelas, textos explicativos etc.). 

Conforme documento da SQA - Systems Quality Assurance (www.spinsp. 
org.br), a gestáo do desempenho procura viabilizar: 

□ O desdobramento da estratégia da organização. 

□ A verificação do desempenho requerido, em funçáo de objetivos e metas. 

□ O estabelecimento de metas de desempenho. 

□ O monitoramento das metas. 

□ O monitoramento do nível de desempenho. 

Mark D. Lutchen (2003), em seu livro Managing ITas a Business , afirma 
que os indicadores de TI devem ser: 

□ Focados em valor. 

□ Baseados em desempenho. 

□ Orientados para a melhoria, náo somente sobre “produção”. 

Ainda de acordo com este autor, os indicadores de TI devem ajudar na 
identificação de causas raízes e orientar a tomada de ações específicas e com¬ 
portamentos na organização de TI, além de promover esforços cooperativos 
entre a TI e o negócio, devendo conter as seguintes propriedades: 

□ Devem ser relevantes. 

□ Devem ser práticos, no sentido de medir aquilo que interessa. 

□ Devem subsidiar a açáo prática. 
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□ Devem ser comunicados. 

□ Devem ter proprietários. 

Mark T. Czarnecki (1999), em seu livro Managing by Measuring , por sua 
vez, define os seguintes atributos para indicadores de desempenho: 

□ São simples e fáceis de ser entendidos. 

□ Têm significado para os interessados ou stakeholders. 

□ Sáo claramente definidos. 

□ Sáo econômicos para serem coletados. 

□ Sáo verificáveis. 

□ Sáo mensuráveis. 

□ Sáo repetíveis. 

□ Divulgam uma mensagem consistente com os valores, as metas e os 
objetivos da organização. 

□ Podem demonstrar uma tendência. 

□ Dirigem as ações corretas. 

□ Atingem o seu propósito. 

A Tabela 3.19 a seguir apresenta, de acordo com Wayne W. Eckerson 
(2009), os tipos de dashboards de desempenho: 



Estratégico 

Tático 

Operacional 

Foco 

Estratégia executiva 

Otimização de processo 

Controle de operações 

Uso 

Gerencial 

Análise 

Monitoramento 

Usuários 

Executivos 

Gerentes 

Técnicos 

Escopo 

Empresa 

Departamental 

Operacional 

Métricas 

Indicadores de resultados 

Indicadores de resultado 
e de progresso 

Indicadores de progresso 

Dados 

Sumarizados 

Detalhados e 
sumarizados 

Detalhados 

Fontes 

Manual, externa 

Manual/sistemas centrais 

Sistemas centrais 

Ciclo de atualização 

Mensal / trimestral 

Diário / semanal 

Durante o dia 

Parecido com 

Um scorecard 

Portal 

Dashboard 


Tabela 3.19 - Tipos de dashboards 
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Finalizando a conceituação deste autor, as principais características de 
dashboards de desempenho eficazes são: 

□ Quanto menos KPIs, melhor. 

□ Deve ter a capacidade de levar o usuário ao detalhe. 

□ Os usuários devem entender para que servem os indicadores. 

□ O usuário sabe como o resultado dos indicadores afeta o resultado 
do negócio. 

□ Os indicadores têm um dono. 

□ O usuário tem que perceber que a informação é acurada, entendendo 
as fontes da informação, como ela é calculada etc. 

□ Deve permitir que o usuário monitore continuamente o impacto dos 
indicadores e faça correlações. 

□ Deve ter indicadores financeiros e não financeiros, que demons¬ 
trem o balanceamento entre atividades, por exemplo, uma meta 
de produtividade é colocada, porém a qualidade não é medida 
concomitantemente. 

□ Os indicadores não podem mascarar outros indicadores. 

□ Os indicadores devem ser validados por todos os interessados 
envolvidos. 

Outra classificação de tipos de dashboards nos é dada por Stephen Few 
(2006). Segundo este autor, os tipos de dashboards são: 

□ Para propósitos estratégicos: fornecem informações sumarizadas 
que os tomadores de decisão necessitam para monitorar a saúde e 
as oportunidades de negócios. Focam em medições de alto nível de 
desempenho, incluindo previsões e comparações com metas ou ava¬ 
liadores de desempenho simples (tais como “bom” ou “ruim”). Não 
necessitam de medições em tempo real. Não são projetados para in¬ 
terações requeridas para análises mais detalhadas. 

□ Para propósitos analíticos: requerem uma abordagem diferente de 
projeto. Nesses dashboards, a informação demanda grande contex¬ 
to, com muitas comparações, história mais detalhada, avaliadores de 
desempenho e visualização de relacionamentos. Suportam interações 
com os dados, com capacidade de drill-down. 
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□ Para propósitos operacionais: sáo utilizados para monitorar ope¬ 
rações e devem ser projetados diferentemente daqueles que supor¬ 
tam os propósitos estratégicos e analíticos. Geralmente sâo aplicados 
para monitoramento de eventos e ação imediata no caso de desvios. 

A Figura 3.44 apresenta um exemplo de um dashboard. 



' > 
Riscos da TI para o negócio 



64 % 


Principais riscos de TI para o negócio 
(probabilidade e impacto) 



19 % 


Montante de exposição ao risco 

V___ 


/ \ 
Demanda 

30%/" \70% 

í ,yà 

83 % 


indicadores da demanda de 
projetos e serviços da Ti para o 
negócio 



76 % 

% do backlog em relação à 


Continuidade do negócio 

30%/" "'\70% 



índice de negódos com plano de 
continuidade testado e mantido 


Acordos de níveis de serviços 



83 % 

Disponibilidade de aplicações e 
serviços para o negócio 


Orçamento 


90 % 

índice de cumprimento do orçamento 
de TI para a unidade de negócio 


Figura 3.44 - Exemplo de um dashboard 

3.6.4 Gestão do desempenho da TI 

O monitoramento do desempenho ocorre quando o resultado atingido é 
comparado com os resultados esperados, a intervalos regulares. Esse monito¬ 
ramento deve responder as seguintes perguntas: 

□ Qual é o nosso desempenho atual? 

□ Há diferenças entre o realizado e o previsto? 
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□ O que está causando desvios? 

□ Qual é a tendência do desempenho? 

□ Como estamos em relação a referenciais de mercado ( benchmarking )? 

□ Quais eventos causam variação positiva ou negativa no desempenho? 

□ Qual é o padrão de desempenho? 

A Figura 3.45 demonstra esses conceitos. 



Figura 3.45 - Padrão de desempenho e informações comparativas 

O modelo de Governança de TI aqui proposto compreende a gestão do 
desempenho: 

□ dos processos e serviços de TI; 

□ dos níveis de serviços; 

□ da estratégia de TI; 

□ de projetos; 

□ do Portfólio de TI; 

□ do valor da TI para o negócio. 


A gestão do desempenho dos processos e serviços visa verificar se o ob¬ 
jetivo de TI foi atendido conforme planejado e entender os motivos da 
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variação positiva ou negativa. Uma vez que se conheçam as causas de va¬ 
riação negativa, ações corretivas, preventivas ou de melhorias no processo 
devem ser recomendadas, monitoradas e implantadas. Em um momento 
posterior, o efeito dessas ações deve ser avaliado para verificar se geraram o 
resultado esperado. 

A gestão do desempenho dos níveis de serviços visa monitorar continua¬ 
mente o atendimento aos acordos de níveis de serviços. No caso de níveis de 
serviços de disponibilidade e capacidade, isso deve ser feito em tempo real. No 
caso do não atendimento, ou seja, se o desempenho do serviço estiver abaixo 
do nível acordado, ações de recuperação devem ser realizadas imediatamente. 
Caso haja grande frequência de não atendimento aos níveis de serviços, ações 
corretivas, preventivas e de melhorias nos processos que apoiam o serviço 
devem ser recomendadas, monitoradas e implantadas. Aqui também, em um 
momento posterior, o efeito dessas ações deve ser avaliado para verificar se 
geraram o resultado esperado. Se esse resultado não foi obtido, novas ações 
devem ser tentadas. 

A gestão do desempenho da estratégia da TI visa monitorar os indicadores 
de progresso, avaliar se os indicadores de resultados foram alcançados e verifi¬ 
car o efeito final no objetivo estratégico estabelecido no BSC. Por exemplo, se 
o objetivo estratégico de entrega no prazo é elevar de 80% para 90%, deve¬ 
mos avaliar se este objetivo foi alcançado através das iniciativas determinadas 
(no BSC) para atendê-lo. O monitoramento dos indicadores de progresso 
permite avaliar se os objetivos resultantes de cada iniciativa poderão ser atin¬ 
gidos. Caso seja concluído que o objetivo resultante de cada iniciativa não 
poderá ser atingido, deve-se iniciar uma ação corretiva, de forma a recuperar 
o projeto da iniciativa. 

Neste caso, as ações de melhoria poderão ocorrer em um novo ciclo de 
planejamento de TI. 

A gestão do desempenho de projeto visa verificar se o progresso, o custo, 
a qualidade e o escopo estão conforme o planejado. Caso haja variação ne¬ 
gativa, deve-se iniciar ações de recuperação, de prevenção e de melhorias, de 
forma a entregar o produto resultante do projeto de acordo com os requisitos 
técnicos e não técnicos. 

A gestão do desempenho do Portfólio de TI serve para avaliar indicadores 
resultantes sobre a razão de projetos previstos que foram entregues (por uni- 
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dade da TI, por unidade de negócio), sobre o objetivo do cumprimento do 
orçamento e sobre o retorno de investimento agregado esperado pelo conjun¬ 
to de projetos. As causas dos desvios devem ser analisadas e ações de melhoria 
devem ser projetadas, monitoradas e implantadas. A gestão do desempenho 
do portfólio é realizada à medida que cada projeto é entregue, no controle 
mensal da execução orçamentária e na avaliação de retorno de investimento, 
algum tempo depois do término de cada projeto. 

A gestão do desempenho do valor da TI para o negócio visa avaliar se os 
objetivos de retorno do investimento (benefícios monetários e não monetá¬ 
rios) do projeto foram atingidos. Às vezes, esta avaliação somente pode ser 
feita meses depois do término do projeto. Caso os objetivos não tenham sido 
atingidos, deve-se identificar o porquê e colher lições aprendidas para melho¬ 
rar as próximas análises de investimento. Dessas lições aprendidas poderão 
surgir recomendações de melhoria de processos de TI. 


3.7 A COMUNICAÇÃO 

A comunicação é crítica para a Governança de TI e para a gestão de TI de 
uma forma geral. 

Geralmente, as áreas de TI sofrem o problema de credibilidade perante as 
unidades de negócio. Portanto, a comunicação, além de ser imperativa para a 
tomada de decisão, também é um meio da TI fazer o seu marketing e mudar 
essa percepção. 

A forma mais eficiente de comunicação do desempenho é um dashboard 
que permita ao executivo consultar e entender, de forma rápida, o desempe¬ 
nho da TI. 

Entretanto, há públicos diferentes com interesses também distintos. 

Os executivos de negócio estão preocupados com informações sobre retor¬ 
no do investimento, níveis de serviços, benefícios dos projetos e serviços ao 
negócio, produtividade da TI, informações sobre tratamento de incidentes 
críticos e status de projetos prioritários. 

A Governança de TI, por sua vez, preocupa-se com temas como índices 
de satisfação dos clientes e usuários, acordos de níveis de serviços, gerencia¬ 
mento da estratégia, monitoramento de projetos estratégicos, alinhamento 
estratégico, níveis de maturidade dos processos de TI, riscos e compliance. 
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indicadores de incidentes, continuidade da TI, formação de recursos, quali¬ 
dade dos fornecedores, indicadores do portfólio de TI, valor da TI para o ne¬ 
gócio etc. As informações tratadas pela Governança de TI estão relacionadas 
à sua função, que é promover o alinhamento da TI ao negócio, a compliance, 
o gerenciamento de riscos, o monitoramento da entrega de valor, o desem¬ 
penho e a comunicação. 

Com grande frequência, em função da natureza do trabalho da Governan¬ 
ça de TI, é preciso identificar indicadores que serão usados uma vez só, para 
permitir análises de causas de variação em desempenho. Esses indicadores 
podem fazer parte de uma base de conhecimento; entretanto, não estarão 
presentes no dashboard. 

Os executivos de cada área funcional da TI têm preocupações estratégi¬ 
cas e táticas, tais como gerenciamento dos níveis de serviços, incidentes e 
problemas, orçamento, o gerenciamento da sua estratégia, recursos huma¬ 
nos, fornecedores, demanda, custos, produtividade, qualidade, inovação e 
processos etc. 

Por fim, o principal executivo de TI deve estar preocupado com todos esses 
temas. 

Portanto, ao definir a comunicação dos resultados da TI para si mesma e para 
o negócio, a TI deve identificar as necessidades das partes interessadas e as carac¬ 
terísticas individuais de cada tomador de decisão. Alguns gostam da figura em 
alto nível, outros desejam maiores detalhes (ou seja, mais drill-down no sistema). 

Teoricamente, poderíamos ter um dashboard para a gestão da TI, um dash¬ 
board para a Governança de TI e outro para os executivos de TI. Portanto, 
antes de inciar o projeto, temos que nos perguntar qual dashboard iremos 
construir, para quem e com qual finalidade. 

O que devemos comunicar, então, em cada dashboard?. Nossa proposição 
está a seguir. 

□ Para os executivos de negócio: 

A Tipo do dashboard . eminentemente estratégico. O gestor cliente 
da TI provavelmente não necessitará de informações analíticas, 
pois não fará análises. Pode ocorrer que queiram saber os moti¬ 
vos de desvios, e neste caso haverá a necessidade de haver alguns 
drill-downs. 

A Visões : Acreditamos que aqui não são necessárias visões do tipo 
BSC. 
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Dashboard de TI para o executivo de negócios 

Temas principais de interesse 

Indicadores/informações 

Criação de valor 

• Retorno do investimento do projeto, atendimento a metas de 
negócios e outros benefícios qualitativos. 

Acordos de níveis de serviços 

• Disponibilidade de aplicações e serviços para o negócio. 

Produtividade da TI 

• Orçamento de Tl/Orçamento da organização. 

• Orçamento de T\lheadcount de TI. 

Inovação da TI 

• Investimento em inovação de TI no negócio. 

Incidentes críticos 

• Informações para acompanhamento das resoluções. 

• Frequência de incidentes por categoria. 

Continuidade do negócio 

• índice de negócios com plano de continuidade testado e 
mantido. 

Riscos da TI para o negócio 

• Principais riscos de TI para o negócio (probabilidade e impacto). 

• Montante de exposição ao risco. 

Projetos prioritários 

• Curva S do projeto. 

• Status do projeto. 

Orçamento 

• índice de cumprimento do orçamento de TI para a unidade de 
negócio. 

Demanda 

• Indicadores da demanda de projetos e serviços da TI para o 
negócio. 

• % do backlog em relação à demanda total. 


Tabela 3.20 - Temas e indicadores para o dashboard dos executivos de negócio 


□ Para a Governança de TI: 

A Tipo do dashboard -. eminentemente estratégico e analítico. A Go¬ 
vernança de TI pode ter outros níveis de dashboard , pois vai ne¬ 
cessitar elaborar análises mais apuradas para identificar e entender 
causas de desvios, de forma que possa recomendar ações correti¬ 
vas, preventivas e melhorias 

A Visões : acreditamos que aqui são necessárias visões de BSC, assim 
como capacidade de drill-downs, tendo em vista a necessidade de 
análise. 
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Dashboard para Governança de TI 


Temas principais de interesse 

Indicadores/informações 

Criação de valor 

• Retorno do investimento do projeto, atendimento a metas de 
negócios e outros benefícios qualitativos. 

Alinhamento de TI 

• Cumprimento das demandas no portfólio de TI. 

• Indicadores de resultados e de progresso do BSC. 

Satisfação dos clientes e usuários 

• índice de satisfação dos clientes e usuários por serviço. 

Excelência operacional e níveis de 
serviços 

• Disponibilidade de aplicações e serviços de TI. 

• Eficiência do atendimento e suporte aos usuários. 

• Entrega de projetos nos prazos acordados com os gestores. 

• Produtividade da TI. 

• índices de qualidade do desenvolvimento. 

• índices de qualidade dos serviços de TI. 

• Custos dos serviços. 

Compliance 

• índice de conformidade com regulamentos internos e 
externos. 

• índice de conformidade da avaliação independente. 

Riscos da TI para o negócio 

• Principais riscos de TI para o negócio (probabilidade e 
impacto). 

• Montante de exposição ao risco. 

Projetos prioritários de TI 

• Curva S do projeto. 

• Status do projeto. 

Gerenciamento de recursos e portfólio de 

TI 

• índice de cumprimento do orçamento de TI para a unidade de 
negócio. 

• Alocação de recursos pelo portfólio de TI. 

• Disciplina orçamentária. 

Demanda 

• % do backlog em relação à demanda total. 

Potencial de futuro 

• Indicadores de treinamento e capacitação do pessoal. 

• Pessoal certificado. 

Prontidão 

• Indicadores de qualidade dos fornecedores. 

• Capacidade de recursos computacionais para a expansão do 
negócio. 

• Maturidade dos processos de TI. 

• “Quantidade de terceiros sobre o total de pessoal empregado”. 

Inovação 

• Indicadores de inovação para os processos de negócio. 

• Indicadores de inovação tecnológica. 

• Inovação em TI. 


Tabela 3.21 - Temas e indicadores para o dashboard de Governança de TI 


Numa visão de BSC, o dashboard para a Governança de TI ficaria assim: 
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Perspectiva do BSC 

Indicadores 

Contribuição ao negócio 

• Retomo do investimento do projeto, atendimento a metas de negócios 
e outros benefícios qualitativos. 

• Cumprimento das demandas no portfólio de TI. 

• Disciplina orçamentária. 

• Exposição ao risco do negócio. 

• Principais riscos de TI. 

• Projetos prioritários do negócio. 

Orientação ao cliente/usuário 

• índice de satisfação dos usuários. 

• Níveis de serviços. 

• Custos dos serviços. 

• Inovação no negócio. 

• % do backlog sobre a demanda total. 

Excelência operacional/processos 
internos 

• Indicadores de resultados e de progresso do BSC. 

• Disponibilidade de aplicações e serviços de TI. 

• Eficiência do atendimento e suporte aos usuários. 

• Entrega de projetos nos prazos acordados com os gestores. 

• Produtividade da TI. 

• índices de qualidade do desenvolvimento. 

• índices de qualidade dos serviços de TI. 

• Custos dos serviços. 

• índice de compliance com regulamentos internos e externos. 

• índice de compliance com avaliação independente. 

• Projetos prioritários de TI. 

Potencial 

• Indicadores de treinamento e capacitação do pessoal. 

• Pessoal certificado. 

• Indicadores de qualidade dos fornecedores. 

• Capacidade de recursos computacionais para a expansão do negócio. 

• Maturidade dos processos de TI. 

• Quantidade de terceiros sobre o total de pessoal empregado. 

• Indicadores de inovação tecnológica. 

• Inovação em TI. 


Tabela 3.22 - Indicadores da Governança de TI em uma perspectiva de BSC 


□ Para os gestores de TI: 

A Tipo do dashboard . eminentemente estratégico e analítico, consi¬ 
derando seu nível de interesse. 

A Visões : acreditamos que aqui são necessárias visões de BSC, assim 
como capacidade de drill-downs , tendo em vista a necessidade de 
análise. Entretanto, para o pessoal de monitoramento de eventos, 
principalmente em operações, são necessários dashboards opera¬ 
cionais. Enquanto a Governança de TI tem uma visão mais agre¬ 
gada, o dashboard dos gestores tem uma visão mais focada no seu 
nível de atuação. 












0 Modelo de Governança de TI 179 


Dashboard para Gestores de TI 


Temas principais de interesse 

Indicadores/informações 

Criação de valor 

• Retorno do investimento do projeto, atendimento a 
metas de negócios e outros benefícios qualitativos. 

Alinhamento de TI 

• Indicadores de resultados e de progresso do BSC. 

Satisfação dos clientes e usuários 

• índice de satisfação dos clientes e usuários por 
serviço. 

Excelência operacional e níveis de serviços 

• Disponibilidade de aplicações e serviços de TI. 

• Eficiência do atendimento e suporte aos usuários. 

• Entrega de projetos nos prazos acordados com os 
gestores. 

• Produtividade da TI. 

• índices de qualidade do desenvolvimento. 

• índices de qualidade dos serviços de TI. 

• Custos dos serviços. 

• Indicadores de incidentes e problemas. 

• Indicadores de segurança da informação. 

• Indicadores de desempenho de processos de TI. 

• Indicadores de recuperação de serviços. 

• Indicadores de atendimento ao usuário. 

Compliance 

• índice de conformidade com regulamentos internos e 
externos. 

• índice de conformidade da avaliação independente. 

Riscos da TI para o negócio 

• Principais riscos de TI para o negócio (probabilidade 
e impacto). 

• Montante de exposição ao risco. 

Projetos prioritários de TI 

• Curva S do projeto. 

• Status do projeto. 

Gerenciamento de recursos e portfólio de TI 

• índice de cumprimento do orçamento de TI para a 
unidade de negócio. 

• Disciplina orçamentária. 

• Reaproveitamento de recursos. 

Demanda 

• % do backlog em relação à demanda total. 

Potencial de futuro 

• Indicadores de treinamento e capacitação do pessoal. 

• Pessoal certificado. 

Prontidão 

• Indicadores de qualidade dos fornecedores. 

• Capacidade de recursos computacionais para a 
expansão do negócio. 

• Maturidade dos processos de TI. 

• Quantidade de terceiros sobre o total de pessoal 
empregado. 
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Dashboard para Gestores de TI 

Temas principais de interesse 

Indicadores/informações 

Inovação 

• inovação em TI. 

Demanda 

• Indicadores de demandas. 

• % do backlog. 


Tabela 3.23 ■ Temas e indicadores para o dashboard de Gestores de T 


□ Para os CIOs: 

A Tipo do dashboard -. eminentemente estratégico. 

A Visões : acreditamos que aqui também sáo necessárias visões de 
BSC, assim como a execução de drill-dowm específicos. 

No caso do CIO, o interesse abrange tanto a visão do cliente como a visão 
da Governança de TI e a visão dos gestores de TI, mas com foco nos indicado¬ 
res principais, de forma que possa ver que o “seu negócio” está criando valor, 
atende aos níveis de serviços, tem excelência operacional e está preparado para 
suportar o crescimento do negócio. 

Para finalizar este tópico, é necessário lembrar que cada gestor tem a sua 
forma de ver o mundo e de gerenciar. O que foi proposto em termos de me¬ 
dições é fruto de nossa experiência e de observações em diversas organizações 
por todo o Brasil. 


3.8 A GESTÃO DA MUDANÇA ORGANIZACIONAL 

A implantação da Governança de TI (e a sua manutenção) é uma jornada 
sem fim. 

Entretanto, traz consigo muitas mudanças na forma de fazer as coisas, não 
somente operacionais, mas, principalmente, na forma de gerenciar. 

O sucesso da implantação da Governança de TI depende fundamental¬ 
mente de um gerenciamento da mudança organizacional. 

Conforme Roberto Ziemer (2007), o modelo tradicional de gerenciamen¬ 
to fracassa por enfatizar apenas a mudança (ou seja, aquilo que acontece fora 
das pessoas), descuidando da transição, do processo interior de adaptação e 
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transformação, que é um passo necessário para que as pessoas consigam lidar 
com novas situações. 

Este autor postula que a fase da transição ou da mudança começa com um 
término, passa por uma zona neutra e tem um reinicio. 

O término representa como a mudança de consciência acerca de velhas 
posturas, comportamentos, identidades, hábitos e crenças, é processada. Para 
o gerenciamento do término, Ziemer propõe: 

□ Reconhecer quem perderá com a mudança. 

□ Reconhecer a importância das perdas subjetivas. 

□ Aceitar as reações emocionais. 

□ Reconhecer as perdas de forma aberta. 

□ Aceitar sintomas de luto. 

□ Compensar as perdas. 

□ Manter as pessoas continuamente informadas sobre as mudanças. 

□ Definir o que acabou e o que não acabou. 

□ Criar rituais para enfatizar o término. 

□ Tratar o passado com respeito. 

A zona neutra é caracterizada pela indefinição, pela confusão e pela falta de 
respostas, pois o indivíduo está confinado entre o antigo e o novo jeito de pen¬ 
sar, entre o conhecido e o desconhecido. A zona neutra é considerada o centro 
do processo de transição e apresenta várias ameaças como: aumento de ansie¬ 
dade, diminuição da motivação, aumento do absenteísmo, retorno de antigas 
fragilidades, excesso de responsabilidades, choque entre os conservadores e os 
futuristas e fragilidades da organização. 

Conforme Ziemer, para gerenciar a zona neutra, é necessário: 

□ Considerar a zona neutra como um período natural. 

□ Redefinir a zona neutra. 

□ Criar sistemas temporários para a zona neutra. 

□ Fortalecer conexões intragrupos. 

□ Estabelecer uma equipe de supervisão da transição. 

□ Usar a zona neutra de forma criativa. 

O reinicio é a fase final do processo de transição, onde as pessoas começam a 
adotar a mudança. Esta fase possui alguns fatores críticos de sucesso, tais como: 
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□ Ser consistente, sem mensagens conflitantes. 

□ Assegurar sucesso rápido. 

□ Simbolizar a nova identidade. 

□ Celebrar o sucesso. 

Outra abordagem para a gestão de mudança é a apresentada por Richard 
Barrett em seu livro Building a Values-Driven Organization: a whole system 
approach to cultural transformation (2006), que propõe um modelo para a 
transformação organizacional. De acordo com este autor, a mudança é um 
modo diferente de agir e de fazer o que fazemos agora de uma forma mais 
eficiente, produtiva e de melhor qualidade, enquanto a transformação é um 
modo diferente de ser, que envolve mudanças nos níveis mais profundos de 
crenças, valores e suposições. 

Para que uma mudança seja efetiva, é necessário que as pessoas tenham co¬ 
nhecimentos e habilidades e operem mudanças comportamentais nas demais 
pessoas. 

Para este autor, as variáveis críticas da mudança são: 

□ Histórico de mudanças: o histórico mostra a percepção que os pro¬ 
fissionais envolvidos na mudança têm sobre a forma como a organi¬ 
zação costuma implementar mudanças. 

□ Resistência/prontidão: mostra o grau de resistência nos três sistemas 
de mudança (comunicação, aprendizagem e recompensa). 

□ Cultura: mostra a diferença entre a cultura percebida e a cultura de¬ 
sejada, e se a mudança que está sendo proposta está adequada à cul¬ 
tura atual e futura (valores, crenças e comportamentos). 

Portanto, a mudança requer que cada pessoa tenha habilidades e co¬ 
nhecimento para agir diferente e ter atitude para agir, ou seja, mudar o seu 
comportamento. 

As razões para falhas, geralmente, são: 

□ Desconhecimento e incerteza sobre o futuro e sobre as razões da 
mudança. 

□ Imposição x Participação. 

□ Comunicação inadequada durante o processo. 
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□ Sistema inadequado de recompensa. 

□ Aprendizagem insuficiente - tanto técnica (agir) como comporta- 
mental (ser). 

Os fatores que devem ser considerados no processo de mudança sáo: 

□ Comunicação sobre a mudança. 

□ Visão (para onde se pretende ir). 

□ Motivação para a mudança. 

□ A competência para a mudança. 

□ Os recursos necessários para a mudança. 

□ O plano de ação para a mudança. 

A Figura 3.46 mostra os impactos de não ter um desses elementos no 
processo. 
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Figura 3.46 - Elementos da mudança organizacional 26 


26 Esta mesma figura aparece no Capítulo 17 deste livro, que mostra o contexto de mudança sob o 
enfoque cultural. 
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3.9 Avaliação independente 

O processo MEA02 —Monitorar, avaliar e medir o sistema de controles in¬ 
ternos, do CobiT [ISACA (2012b)], tem como propósito obter transparência 
para as principais partes interessadas acerca da adequação do sistema de controles 
internos e desta forma prover confiança nas operações e no atingimento dos objeti¬ 
vos corporativos, e uma compreensão adequada dos riscos residuais. 

Um dos fatores que contribuem para este propósito está descrito em uma 
de suas práticas de gestáo: assegurar que os avaliadores 27 sejam independentes 
(das funções, grupos ou organizações no escopo) e qualificados . 

Seguindo essa linha de pensamento, é recomendável que as organizações 
possuam um modelo de avaliação independente (interna ou externa) sobre a 
conformidade de TI com leis e regulamentos relevantes; com políticas, pa¬ 
drões e procedimentos organizacionais; com práticas geralmente aceitas e com 
um efetivo e eficiente desempenho de TL 

A avaliação independente é realizada por empresas de auditoria e é chamada 
de auditoria de terceira parte, onde a organização contrata a auditoria externa. 

Organizações que já possuem governança corporativa madura têm, em seu 
sistema de controles internos e gestáo de riscos, auditorias periódicas realiza¬ 
das por empresas especializadas e com contratos de longa duraçáo. 

A auditoria foca nos controles internos aplicados a TL Seguem alguns 
exemplos de controles internos em TL 

□ Em projetos de desenvolvimento de sistemas, a auditoria pode veri¬ 
ficar se estes estáo sendo desenvolvidos conforme a metodologia de 
desenvolvimento preconizada e utilizando uma metodologia de ge¬ 
renciamento de projetos. 

□ No gerenciamento de serviços, a auditoria pode verificar se os planos 
de continuidade de serviços foram elaborados e foram testados, se¬ 
guindo normas e políticas da organização. 

Entretanto, a auditoria somente irá verificar o que foi colocado dentro 
do sistema de controle interno da organização. Nem tudo é colocado nesse 
sistema, pois dependerá do grau de risco que o controle representa para o ne¬ 
gócio. Geralmente, mapas de riscos dos processos de negócio apontam quais 
controles internos devem ser incluídos no sistema. 


27 O texto original do CobiT utiliza o termo assurance providers. 
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Por exemplo, supondo que a disponibilidade de aplicações de TI é um 
risco para certos processos de negócio críticos da organização. Neste caso, 
devem entrar para o sistema de controle interno o processo de gerenciamento 
de disponibilidade e o processo de continuidade de serviços. 

Porém, a gestão da TI pode incluir outros itens não tão críticos para o risco 
do negócio, mas importantes para o desempenho dos serviços de TI, confor¬ 
me descrito nos acordos de níveis de serviços. 

Como conselho, sugerimos que somente sejam colocados dentro do siste¬ 
ma de controle interno processos testados e que demonstraram que, efetiva¬ 
mente, agregam valor para o negócio e permitem uma gestão eficaz e eficiente 
da TI na organização. 


3.10 Riscos e compliance 
3 . 10.1 Gestão de riscos 

Para o CobiT [ISACA (2012b)], a gestão de riscos relacionados à TI deve 
ser realizada de forma integrada à gestão corporativa de riscos, com uma abor¬ 
dagem de balanceamento de custos e benefícios. Neste sentido, recomenda 
criar e manter uma estrutura de gestão de risco que documente um nível 
comum e acordado de riscos de TI, estratégias de mitigação e riscos residuais. 

Qualquer impacto em potencial nos objetivos da empresa causado por um 
evento não planejado deve ser identificado, analisado e avaliado. Estratégias 
de mitigação de risco devem ser adotadas para minimizar o risco residual a 
níveis aceitáveis. O resultado da avaliação deve ser entendido pelas partes 
interessadas e expresso em termos financeiros, para permitir que as partes 
interessadas alinhem o risco a níveis de tolerância aceitáveis. 

Tendo como inspiração o CobiT, o modelo de governança proposto adota 
como práticas para a gestão de riscos de TI: 

□ Alinhar a gestão de riscos de TI com o sistema de gestão de riscos 
da organização: significa que a gestão de riscos da TI deve ser integrada 
com a gestão de riscos da organização. Em organizações com governança 
corporativa madura, é estabelecido um sistema de gestão de riscos ope¬ 
racionais já com metodologias estabelecidas e com mapas de risco por 
processo de negócio ou por serviços (no caso de bancos, o sistema de ges¬ 
tão de riscos abrange riscos de crédito, riscos operacionais e de mercado). 



186 Implantando a Governança de TI - 4 a edição 


□ Estabelecimento do contexto do risco: significa estabelecer o con¬ 
texto ao qual a estrutura de avaliação de risco é aplicada para assegu¬ 
rar resultados esperados. Isso inclui a definição dos contextos interno 
e externo de cada avaliação de riscos, o objetivo da avaliação e os 
critérios a serem usados na avaliação. 

□ Manutenção de um perfil de riscos: significa coletar dados e identi¬ 
ficar eventos (importantes ameaças reais que exploram significativas 
vulnerabilidades) com potenciais impactos negativos nos objetivos 
ou nas operações da organização, incluindo aspectos de negócios, re¬ 
gulamentação, aspectos jurídicos, tecnologia, parcerias de negócio, 
recursos humanos e operacionais. Deve-se determinar a frequência 
esperada e a natureza do impacto e manter esta informação, assim 
como registrar e manter um histórico dos riscos relevantes. 

□ Avaliação de risco: avaliar regularmente a probabilidade e o impac¬ 
to de todos os riscos identificados, utilizando métodos qualitativos e 
quantitativos. A probabilidade e o impacto associado ao risco ineren¬ 
te e residual devem ser determinados individualmente, por categoria 
e com base no portfólio da organização. 

□ Resposta ao risco: significa desenvolver e manter um processo de 
respostas a riscos para assegurar que controles com uma adequada 
relação custo-benefício mitiguem a exposição aos riscos de forma 
contínua. O processo de resposta ao risco deve identificar estratégias 
de risco, tais como evitar, reduzir, compartilhar ou aceitar o risco, 
articular e determinar responsabilidades e considerar os níveis de to¬ 
lerância definidos. 

□ Manutenção e monitoramento do plano de ação de risco: signi¬ 
fica priorizar e planejar as atividades de controle em todos os níveis 
da organização para implementar as respostas aos riscos identificadas 
como necessárias, incluindo a identificação de custos, benefícios e 
responsabilidade pela execução. Envolve também obter aprovações 
para ações recomendadas e aceitação de quaisquer riscos residuais e 
assegurar que as ações aprovadas sejam assumidas pelos donos dos 
processos afetados, assim como monitorar a execução dos planos e 
reportar qualquer desvio para a alta direção. 

Em termos práticos, este trabalho deve ser feito juntamente com a área de 
gestão de riscos da organização. 
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Caso esta área não exista dentro da sua organização, você deve se concen¬ 
trar nos riscos dos principais processos de negócio, ou seja, naqueles principais 
geradores de receitas ou cuja inoperância possa trazer prejuízos financeiros ou 
de imagem para a organização. 

Para tanto, você deverá fazer um mapa simples do processo de negócio e 
identificar qual o serviço mais importante do apoio da TL A partir daí, deverá 
identificar possíveis causas de ocorrência de riscos e depois levantar eventos 
que já tenham ocorrido em relação ao serviço e categorizá-los conforme as 
causas para identificar probabilidades de ocorrência. 

Vamos imaginar o seguinte processo de negócio, como mostrado na Figura 
3.47, a seguir. 

O exemplo da figura mostra os principais riscos da TI para cada etapa do 
processo do negócio e relaciona os principais processos e recursos de TI que 
podem ser causadores da ocorrência do risco. 

O investimento necessário para a mitigação do risco deverá ser balizado pelo 
nível de tolerância de riscos do dono do processo e também da administração. 

Se você for um administrador esperto, é importante que obtenha uma 
comunicação oficial do dono do processo sobre a tolerância ao risco. Mas, de 
qualquer forma, você terá que comunicar essa tolerância e as probabilidades 
de ocorrência do risco correspondente. 
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Figura 3.47 - Exemplo de mapa de risco 
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Os autores tiveram uma experiência em anos recentes com a avaliação 
de um sistema de cobrança em uma empresa de “cobrança”. Na realidade, 
o sistema cobria todos os processos de negócio da empresa, estava imple¬ 
mentado em uma plataforma de software obsoleta e era processado em um 
servidor PC Pentium sem nenhuma redundância, sendo que o ambiente era 
muito informal e amador. Neste caso, a tolerância de risco do negócio era 
altíssima. 

Numa situação similar a esta você deve comunicar a administração sobre 
os graves riscos que o negócio está correndo e, obviamente, mostrar as solu¬ 
ções e explicar qual o tamanho da perda financeira em que a empresa está 
incorrendo por não se proteger. 


3 . 10.2 COMPLIANCE 

De acordo com o documento “Função de Compliance ”, publicado pela 
Pricewaterhouse Coopers em 2009, conjuntamente com a Associação 
Brasileira de Bancos Internacionais e a Federação Brasileira de Bancos 
(vide ABBI 2009), “ compliance é o dever de cumprir, estar em conformidade 
e fazer cumprir regulamentos internos e externos impostos às atividades da 
instituição ”. 

Aplicando-se isso à TI, refere-se à conformidade da área de TI da organiza¬ 
ção a regulamentos internos e externos impostos às suas atividades. 

Em determinadas organizações, principalmente instituições financeiras e 
de seguros em geral, conforme regulamentos do Banco Central e da SUSEP, 
deve haver uma área de compliance com a missão de: 

Assegurar, em conjunto com as demais áreas, a adequação, o fortalecimen¬ 
to e o funcionamento do Sistema de Controles Internos da Instituição, pro¬ 
curando mitigar os riscos de acordo com a complexidade de seus negócios, 
bem como disseminar a cultura de controles para assegurar o cumprimento 
de leis e regulamentos existentes. Além disso, atuar na orientação e cons¬ 
cientização à prevenção de atividades e condutas que possam ocasionar 
riscos à imagem da instituição. 

O foco do compliance é monitorar os riscos do não atendimento aos regu¬ 
lamentos internos e externos. 
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Em organizações com governança corporativa madura, a área de TI tem re¬ 
presentantes de compliance que seguem os procedimentos da área responsável 
pelo compliance da organização. 

Neste caso, o responsável local pelo compliance monitora riscos de com¬ 
pliance em TI, realizando testes sobre controles, comunicando resultados e 
gerando indicadores e relatórios de compliance. 

O compliance é um tema importante para a Governança de TI, pois 
assegura que as normas internas e externas estejam sendo respeitadas e 
seguidas. 

O náo atendimento às normas internas e externas pode ter como 
consequência: 

□ Multas de órgáos reguladores por náo estar em conformidade. 

□ Problemas de conduta ética trazendo prejuízos para a organização. 

□ Aumento do custo de operações da organização pelo uso de práticas 
fracas. 

□ Ineficiência das operações, prejudicando a qualidade de serviços re¬ 
querida pelo negócio. 

□ Altos custos de compliance devidos à duplicidade de controles. 

Bem, agora que vimos o modelo proposto, vamos discutir os principais 
modelos aplicáveis à Governança de TI. 




Os Papéis da Governança de TI na 
Organização 


Umas das grandes questões que se coloca sobre a Governança de TI é quanto 
ao seu papel na organização de TI e fora dela (ou seja, “quem faz o quê”). Nossa 
experiência tem demonstrado que a falta de papéis e responsabilidades bem de¬ 
finidas é um grande obstáculo para a implantação da Governança de TI. 

Em determinadas organizações, algumas funções da Governança de TI 
estão integradas à Governança Corporativa, como, por exemplo, gestão de 
riscos, controles internos, segurança da informação, priorização de investi¬ 
mentos, orçamento de investimentos, e geralmente são executadas por outras 
áreas da organização. 

A definição de responsabilidades depende da característica do modelo de 
Governança de TI desenhado para a organização. 

O que temos observado no mercado são as seguintes abordagens: 

□ Criação de uma área ou departamento específico para lidar com a 
Governança de TI, com a função de dar visibilidade ao CIO acerca da 
aderência das demais áreas de TI às estratégias de TI, regras, políticas 
e práticas de gestão e operação de serviços. 

□ Criação de uma área ou departamento de Governança de TI com res¬ 
ponsabilidade de dirigir a implantação das políticas, regras e práticas 
de gestão e operação de serviços. 

□ Alguns profissionais, em geral ligados diretamente ao CIO, são 
designados para implantar a Governança de TI, mas não há uma 
área específica para essa finalidade. Geralmente, o foco recai sobre 
a implantação de boas práticas de gestão e operação de serviços 
de TI. 
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□ A implantação de Governança de TI é um programa para o qual é 
designado um gerente do programa, vinculado ao CIO. Por meio 
dele, a organização gerencia a implantação das melhores práticas pe¬ 
las demais áreas de TL O programa pode ser encerrado quando os 
objetivos de maturidade dos processos são alcançados. 

□ Não há uma organização, mas somente projetos evolutivos, onde ge¬ 
ralmente o líder da mudança é o CIO, que utiliza com frequência 
consultorias externas para a implantação das melhores práticas. 

Em nossa visão, acreditamos que a adoção de arquétipos como os anterior¬ 
mente descritos depende das características de cada organização. 

Não há uma melhor abordagem, mas sim a mais adequada para cada orga¬ 
nização em um determinado momento de sua história. 

Em grandes organizações, por exemplo, dificilmente encontra-se uma Go¬ 
vernança de TI com poderes para intervir nas áreas de TI. Geralmente, nesses 
casos, é recomendável que a área de Governança de TI faça um trabalho de 
indução e promoção, dando a visibilidade para o CIO intervir e cobrar. 

Em organizações de porte médio e pequeno, provavelmente o modelo mais 
adequado seja uma área de Governança de TI com mais poderes, que dirija, 
de fato, a implantação das melhores práticas, que gerencie o risco de TI e de¬ 
monstre o valor da TI para o negócio. 

Lembramos, porém, que a Governança de TI é de responsabilidade de 
todos, pois quem implanta e mantém as boas práticas e a estratégia de TI são, 
de fato, as demais áreas de TL 

Considerando nosso modelo genérico, propomos uma distribuição das 
responsabilidades sobre a Governança de TI, conforme mostra a Tabela 4.1. 


Funções da 
Governança 
ede 

Gestão da TI 

Diretoria 

Executiva 

CIO 

Governança 
de TI 

Áreas 

Funcionais 

da TI 

Áreas de 
Controle, 
Risco e 
Compliance 

Risco e 
Compliance 

Aprova a política 
de risco e 
compliance da 
organização. 

Faz com que a 
área de TI siga a 
política de risco 
da organização 
e monitora os 
riscos da TI para 
o negócio. 

Segue a política 
e os métodos, 
mas trabalha com 
os indicadores e 
monitora os riscos. 

Seguem 
a política, 
desenvolvem e 
implantam ações 
de mitigação. 

Verificam se 
as ações de 
mitigação foram 
implantadas e 
foram efetivas. 
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Funções da 
Governança 
ede 

Gestão da TI 

Diretoria 

Executiva 

CIO 

Governança 
de TI 

Áreas 

Funcionais 

da TI 

Áreas de 
Controle, 
Risco e 
Compliance 

Avaliação 

Independente 

Aprova a política 
de controles 
internos da 
organização. 

Faz com que 
a área de TI 
siga a política 
de controles 
internos da 
organização 
e monitora as 
pendências. 

Segue a política, 
trabalha com 
indicadores 
e monitora a 
resolução das não 
conformidades. 

Seguem a 
política e 
resolvem os itens 
não conformes. 

Éde 

responsabilidade 
da área de 
auditoria interna 
da organização. 

Gestão da 

Mudança 

Organizacional 

Aprova mudanças 
na política de 
pessoal e de 
desenvolvimento 
de recursos 
humanos. 

Aprova o 
programa 
de mudança 
organizacional 
e lidera a sua 
implantação. 

A Governança de 

TI pode montar e 
dirigir o programa 
de gerenciamento 
da mudança. 

Participam 
do programa 
de mudança, 
liderando a 
mudança na sua 
área, colocando 
seu pessoal para 
ser treinado e 
capacitado e 
implantam as 
melhores práticas 
em sua área. 


Alinhamento 

Estratégico 

Define e comunica 
a estratégia da 
organização e 
decide sobre as 
priorizações de 
investimentos, 
aprova o 

orçamento da área 
de TI e monitora 
os projetos 
estratégicos de 
negócios e TI. 

Define a 
estratégia de TI 
e a comunica 
para as demais 
áreas funcionais 
de TI, propõe 
as prioridades 
para a Diretoria 
Executiva e 
gerencia o 
portfólio de TI. 

Dirige o processo 
de planejamento 
de TI e suas 
revisões, verifica 
a aderência dos 
planos de TI com 
a estratégia de TI, 
estrutura o portfólio 
de TI, e consolida 
o orçamento de TI. 

Participam da 
elaboração da 
estratégia de 

TI, elaboram, 
gerenciam e 
implantam seus 
planos internos 
alinhados com 
a estratégia de 

TI, e elaboram 
os respectivos 
orçamentos. 


Entrega de 

Valor 

Monitora os 
projetos de 
negócios e TI 
estratégicos. 

Gerencia o 
portfólio de TI, 
a demanda, o 
relacionamento 
com clientes e 
fornecedores 

Monitora o portfólio 
de TI, verifica 
se os planos de 

TI estão sendo 
implantados e 
fornece visibilidade 
para o CIO. 

Desenvolvem 
projetos, 
fornecem 
serviços e geram 
inovações de 
acordo com 
as melhores 
práticas definidas 
pelo plano de 

TI, atendem 
a clientes e 
gerenciam 
serviços de 
terceiros. 
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Funções da 
Governança 
ede 

Gestão da TI 

Diretoria 

Executiva 

CIO 

Governança 
de TI 

Áreas 

Funcionais 

da TI 

Áreas de 
Controle, 
Risco e 
Compliance 

Gerenciamento 
de Recursos 

Recebe informes 
sobre a execução 
orçamentária e de 
investimentos da 
área de TI. 

Gerencia o uso 
de recursos e 
define ações 
para a sua 
otimização, 
gerencia o 
orçamento e 
investimentos da 
área e reporta- 
se à Diretoria 
Executiva. 

Verifica 
oportunidades 
de otimização 
de recursos, 
acompanha a 
realização do 
orçamento e de 
investimentos. 

Propõem e 
implantam ações 
para a otimização 
de recursos, 
gerenciam 
os recursos 
sob a sua 
responsabilidade 
e realizam 
o controle 
orçamentário e 
de investimentos 
em sua área de 
atuação. 


Gestão do 
Desempenho 


Gerencia o 
desempenho 
da TI, gerencia 
a estratégia 
de TI, solicita 
recuperação de 
desempenho 
para os seus 
gerentes 
e redefine 
estratégias. 

Propõe métodos 
de gerenciamento 
do desempenho, 
mantém o 
dashboard de 
governança de 

TI, monitora o 
desempenho 
e a criação de 
valor da TI e faz 
recomendações. 
Avalia a 
efetividade das 
melhores práticas 
sobre a geração 
de valor e sobre o 
risco da TI. 

Gerenciam o 
desempenho de 
seus projetos, 
assim como 
a estratégia, 
os serviços e 
as inovações, 
realizam 
correções, 
fornecem os 
indicadores para 
a Governança de 
TI e para o CIO. 


Comunicação 

Recebe os 
informes de 
desempenho da 

TI e da criação 
de valor através 
de dashboard 
executivo, 
solicita ações de 
recuperação de 
melhoria. 

Recebe os 
informes de 
desempenho 
e criação de 
valor, avalia a 
estratégia de 

TI e reporta- 
se à Diretoria 
Executiva. 

Consolida 
indicadores de 
desempenho e de 
valor e específicos 
de interesse para 
a Governança de 

TI e os comunica 
ao CIO. Mantém o 
dashboard de TI. 

Comunicam os 
resultados de seu 
desempenho e 
criação de valor, 
alimentando o 
dashboard de 
gestão de TI. 



Tabela 4.1 - Responsabilidades pela Governança de TI 












Modelos de Melhores Práticas e o 
Modelo de Governança de TI 


Nas duas últimas décadas vem surgindo e sendo elaborada uma série de 
modelos de melhores práticas para TI. Alguns desses modelos são originais 
e outros são derivados e/ou evoluídos de outros modelos. Os principais 
modelos em voga atualmente, citados no meio acadêmico e profissional, 
relacionados com a Governança de TI, estão apresentados na Tabela 5.1, a 
seguir: 


Modelo de melhores práticas 

Escopo do modelo 

ISO/IEC 38500 

Trata a Governança Corporativa de TI. 

CobiT 

Modelo abrangente aplicável para a governança e o gerenciamento 
da TI em âmbito corporativo. 

ISO 31000 

Trata dos princípios e guias para o gerenciamento de riscos. 

CMMI - Capability Maturíty Model 
Integration 

Desenvolvimento de produtos e projetos de sistemas e software. 

MPS.br para Software 

Modelo brasileiro para a melhoria do processo de software. 

ITIL -Information Technology 
Infrastructure Library 

Serviços de TI, segurança da informação, gerenciamento da 
infraestrutura, gestão de ativos e aplicativos etc. 

ISO/IEC 20000 

Norma abordando requisitos e melhores práticas para o 
gerenciamento de serviços de TI. 

MPS.br para Serviços 

Modelo brasileiro para a melhoria das práticas de serviços. 

USMBOK - Universal Service 
Management Body of Knowledge 

Gerenciamento de serviços de qualquer natureza (inclusive de TI). 

ISO/IEC 27001 e ISO/IEC 27002 

Requisitos e código de prática para a gestão da segurança da 
informação. 
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Modelo de melhores práticas 

Escopo do modelo 

Modelos ISO - International 
Organization for Standardization 

Sistemas da qualidade, ciclo de vida de software, teste de software 
etc. 

eSCM-SP e eSCM-CL - Service 
Provider Capability Maturity Model 

Outsourcing em serviços que usam TI de forma intensiva. 

PRINCE2 - Project in controlled 
environment. 

Metodologia de gerenciamento de projetos. 

PMBOK - Project Management Body 
ofKnowledge 

Base de conhecimento em gestão de projetos. 

Modelos PMI para Gestão de Portfolio 
e Programas 

Base de conhecimento para gerenciamento de portfolios e 
programas. 

SCRUM 

Método ágil para o gerenciamento de projetos. 

BSC - Balanced Scorecard 

Metodologia de planejamento e gestão da estratégia. 

Seis Sigma 

Metodologia para melhoria da qualidade de processos. 

SAS 70 - Statement on Auditing 
Standards for Services organizations 

Regras de auditoria para empresas de serviços. 

SFIA - Skills Framework for the 
Information Age 

Modelo para gestão de competências direcionado aos profissionais 
de TI. 

TOGAF - The Open Group 

Architecture Framework 

Modelo que trata o desenvolvimento e a evolução de arquiteturas de 

TI. 

BPM CBOK - Business Process 
Management Body of Knowledge 

Corpo de conhecimento para o gerenciamento de processos de 
negócio. 

BABOK - The Guide to the Business 
Analysis Body of Knowledge 

Guia de conhecimento para a prática de análise de negócio. 

DAMA DMBOK - Data Management 
Body of Knowledge 

Guia de conhecimento para a disciplina de gestão de dados. 


Tabela 5.1 - Principais modelos de melhores práticas 


A Figura 5.1, a seguir, mostra como esses modelos se posicionam dentro do 
nosso modelo de Governança de TL 
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ALINHAMENTO 
ESTRATÉGICO E ■ 
COMPUANCE I 




Alinhamento 

estratégico 


Princípios de TI 


Gestão da 
demanda 


Necessidades de 
aplicações 


Arquitetura de TI 


Infraestrutura de 


Objetivos de 
desempenho 


Capacidade 


Sourcing 


Segurança da 
informação 


Competências 


Processos e 
organização 


DECISÃO, 
COMPROMISSO, 
PRIORIZAÇÃO E 
ALOCAÇÃO DE 
RECURSOS 


Mecanismos de 
decisão 


Critérios de 
priorização 


Portfólio de TI 


COBlT 

ISO/l EC 27000 
ITIL 

USMBOK 
L BABOK 
BPM CBOK 
TOGAF 
eSCM 
SFIA 
BSC 


COBlT 
Gestão de 
Portfólio - 
PMI 


r::= 


i> II 


PMBOK 

PRINCE2 

ITIL 

USMBOK 

eSCM 

CMMI 

SCRUM 

MPS.br 

CobiT 


BPM CBOK 
BABOK 
ISO/l EC 20000 
ISO/IEC 27000 
Seis Sigma 
SAS70 
ISO 

DMBOK 



Figura 5.1 - Os modelos de melhores práticas no contexto da Governança de TI 


Conforme a Figura 5.1, os modelos de melhores práticas auxiliam a im¬ 
plantação da Governança de TI, mas não são panaceias. Para usar esses mo¬ 
delos, é importante que a organização elabore sua própria arquitetura de pro¬ 
cessos de TI, priorizando o que é importante para a agregação de valor para 
o negócio e balanceando com os riscos de TI para o negócio, assim como os 
riscos para a continuidade, para a flexibilidade futura dos processos e para o 
desenvolvimento de novos produtos e serviços. 

Ao definir a cadeia de valor e sua arquitetura de processos, podemos em¬ 
pregar várias diretrizes e práticas de vários modelos ao mesmo tempo. Por 
exemplo, podemos selecionar a área de processo de Medição e Análise do 
CMMI (no nível 3) e empregá-la para implantar um processo de medição do 
desempenho dos serviços de TI. 

Como se propaga no mercado, a Governança de TI não se restringe so¬ 
mente à implantação desses modelos de melhores práticas. Entretanto, é im¬ 
portante conhecê-los em termos de seus objetivos, estruturas e aplicabilidade. 
Nos capítulos seguintes deste livro, veremos uma descrição dos principais mo¬ 
delos aplicáveis no contexto da Governança de TI. 
















































































































Modelos Abrangentes de Governança 
DE TI 


No contexto atual do mercado, existem alguns modelos de referência que 
abordam a Governança de TI de forma holística, abrangendo os seus prin¬ 
cípios e diretrizes tanto no âmbito das organizações de TI quanto no seu 
relacionamento com as demais organizações que fazem parte da sua cadeia de 
valor (clientes, fornecedores, parceiros etc.). 

Entre esses modelos, destacam-se a norma ISO/IEC 38500 e o CobiT. 
Neste capítulo, são apresentados de forma resumida os princípios e processos 
relacionados a esses modelos. 


6.1 ISO/IEC 38500 - Governança 

CORPORATIVA DE TECNOLOGIA DA INFORMAÇÃO 

O objetivo desta norma é fornecer uma estrutura de princípios para os 
dirigentes (incluindo proprietários, membros do conselho de administração, 
diretores, parceiros, executivos seniores ou similares) utilizarem na avaliação, 
no gerenciamento e no monitoramento do uso da tecnologia da informação 
em suas organizações. 

A norma já se encontra localizada pela Associação Brasileira de Normas 
Técnicas (ABNT) como Norma Brasileira NBR ISO/IEC 38500:2009. 


6 . 1.1 Aplicação 

Esta norma é aplicável a todas as organizações, incluindo organizações pú¬ 
blicas e privadas, entidades governamentais e organizações sem fins lucrativos. 
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Da mesma forma, aplica-se a organizações de todos os tamanhos (pequenas e 
grandes), independentemente da extensão de seus usos de TI. 

Para a norma, Governança Corporativa de TI significa: avaliar e direcio¬ 
nar o uso da TI para dar suporte à organização e monitorar seu uso para 
realizar os planos. Inclui a estratégia e as políticas de uso da TI dentro da 
organização. 


6 . 1.2 Objetivos 

O propósito da norma é promover o uso eficaz, eficiente e aceitável da TI 
nas organizações para: 

□ Garantir às partes interessadas (incluindo consumidores, acionistas e 
funcionários) que, se a norma for seguida, pode-se confiar na gover¬ 
nança corporativa de TI na organização. 

□ Informar e orientar os dirigentes quanto ao uso da TI em suas 
organizações. 

□ Fornecer uma base para uma avaliação objetiva da governança corpo¬ 
rativa de TI. 


6 . 1.3 Estrutura da norma 

6.1.3.1 Estrutura para uma boa governança corporativa de TI 

A norma preconiza seis princípios que caracterizam uma boa governança 
de TI: 

□ Princípio 1 - Responsabilidade: os indivíduos e grupos dentro 
da organização compreendem e aceitam suas responsabilidades 
com respeito ao fornecimento e à demanda de TI. Aqueles res¬ 
ponsáveis pelas ações também têm autoridade para desempenhar 
tais ações. 

□ Princípio 2 - Estratégia: a estratégia de negócio da organização leva 
em conta as capacidades atuais e futuras de TI. Os planos estratégicos 
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para TI satisfazem as necessidades atuais e contínuas da estratégia de 
negócio da organização. 

□ Princípio 3 - Aquisição: as aquisições de TI são feitas por razões 
válidas, com base em análise apropriada e contínua, com tomada de 
decisão clara e transparente. Existe um equilíbrio entre benefícios, 
oportunidades, custos e riscos, de curto e longo prazo. 

□ Princípio 4 - Desempenho: a TI é adequada ao propósito de apoiar 
a organização, fornecendo serviços, níveis de serviço e qualidade de 
serviço, necessários para atender aos requisitos atuais e futuros de 
negócio. 

□ Princípio 5 - Conformidade: a TI cumpre com toda a legislação e 
os regulamentos obrigatórios. As políticas e práticas são claramente 
definidas, implementadas e fiscalizadas. 

□ Princípio 6 - Comportamento Humano: as políticas, práticas e 
decisões de TI demonstram respeito pelo comportamento humano, 
incluindo as necessidades atuais e futuras de todas as “pessoas no 
processo”. 

6.1.3.2 Modelo 

A norma preconiza que os dirigentes governem a TI através de três tarefas 
principais: 

□ Avaliar o uso atual e futuro da TI. 

□ Orientar a preparação e a implementação de planos e políticas para 
assegurar que o uso da TI atenda aos objetivos do negócio. 

□ Monitorar o cumprimento das políticas e o desempenho em relação 
aos planos. 

A Figura 6.1 mostra o modelo do ciclo Avaliar-Dirigir-Monitorar. 
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Figura 6.1 - Modelo para governança corporativa de TI 
Fonte: ABNT (2009) 

Para a norma, avaliar significa que os dirigentes devem examinar e avaliar 
o uso atual e futuro da TI, incluindo estratégias, propostas e arranjos de for¬ 
necimento (interno, externo ou ambos). 

Dirigir significa a designação de responsabilidades, pelos dirigentes, e a 
preparação e implementação dos planos e políticas, estabelecendo o direcio¬ 
namento dos investimentos nos projetos e operações de TI. As políticas de¬ 
vem estabelecer comportamentos no uso da TI na organização, assim como 
incentivar que os gerentes sigam os seis princípios da boa governança de TI. 

Por fim, os dirigentes devem monitorar através de sistemas de mensuração 
apropriados, verificando se o desempenho está de acordo com os planos e os 
objetivos de negócio e se a TI está em conformidade com as obrigações exter¬ 
nas e práticas internas de trabalho. 

A Tabela 6.1 mostra o ciclo Avaliar-Dirigir-Monitorar para cada princípio 
da norma. 
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Princípio 

Avaliar 

Dirigir 

Monitorar 

Responsabilidade 

• Opções de 
delegação de 
responsabilidades. 

• Competências 
daqueles a quem 
for delegada a 
responsabilidade 
pela tomada de 
decisão em TI. 

• Exigir que os planos sejam 
cumpridos de acordo com as 
responsabilidades delegadas. 

• Que os mecanismos 
apropriados de 
governança de TI sejam 
estabelecidos. 

• Que aqueles 
que receberam 
responsabilidades 
reconheçam e 
compreendam suas 
responsabilidades. 

• 0 desempenho daqueles 
a quem foi delegada 
responsabilidade pela 
governança de TI. 

Estratégia 

• Os 

desenvolvimentos 
em TI para que esta 
esteja apoiando o 
negócio. 

• 0 alinhamento 
da TI com planos 
e políticas da 
organização. 

• 0 risco da TI para o 
negócio. 

• A preparação de planos 
e políticas para que a 
organização seja beneficiada 
com o uso da TI. 

• Encorajar os dirigentes a 
apresentar propostas para 
usos inovadores de TI. 

• 0 progresso das 
propostas de TI 
aprovadas. 

• Se os benefícios com 
a TI estão sendo 
alcançados. 

Aquisição 

• Opções de 
fornecimento da TI. 

• Orientar para que os ativos de 
TI sejam adquiridos de forma 
apropriada. 

• Certificar-se de que os 
acordos de fornecimento darão 
suporte às necessidades da 
organização. 

• Os investimentos de TI. 

• Compreensão mútua dos 
objetivos da aquisição 
por parte da organização 
e dos fornecedores. 

Desempenho 

• Proposições dos 
gerentes. 

• Riscos à 
continuidade do 
negócio. 

• Riscos à integridade 
da informação e à 
proteção dos ativos 
de TI. 

• A eficácia eo 
desempenho 
do sistema de 
Governança de TI 
da organização. 

• Assegurar a alocação de 
recursos suficientes, de forma 
a garantir que a TI atenda às 
necessidades da organização, 
de acordo com prioridades 
acordadas e restrições 
orçamentárias. 

• Até que ponto a TI dá 
suporte ao negócio. 

• Se os recursos e o 
orçamento foram 
priorizados de acordo 
com os objetivos do 
negócio. 

• Se as políticas são 
seguidas corretamente. 
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Princípio 

Avaliar 

Dirigir 

Monitorar 

Conformidade 

• Até que ponto a 

TI cumpre com 
as obrigações 
de conformidade 
interna e externa 
(compliance). 

• Conformidade 
interna com o 
seu sistema de 
governança de TI. 

• Exigir dos responsáveis que: 

- a TI esteja de acordo com 
as exigências legais; 

- políticas sejam 
estabelecidas e cumpridas; 

- ações de TI sejam éticas. 

• 0 cumprimento e a 
conformidade da TI 
por meio de relatos 
apropriados e práticas 
de auditoria. 

• As atividades de TI 
para assegurar o 
cumprimento das 
exigências ambientais, 
de privacidade, de 
gerenciamento do 
conhecimento estratégico 
e de preservação da 
memória organizacional. 

Comportamento 

Humano 

• As atividades de TI 
para garantir que 
os comportamentos 
humanos sejam 
identificados e 
apropriadamente 
considerados. 

• Exigir que as atividades de 

TI sejam compatíveis com as 
diferenças de comportamento 
humano. 

• Exigir que riscos, oportunidades, 
constatações e preocupações 
possam ser identificados e 
relatados por qualquer pessoa a 
qualquer momento. 

• Atividades de TI 
para garantir que 
os comportamentos 
humanos identificados 
permaneçam relevantes 
e que lhes sejam dadas a 
devida atenção. 


Tabela 6.1 - Princípios da boa governança de TI versus ciclo avaliar-dirigir-monitorar 
Adaptado de ABNT (2009) 


6 . 1.4 Benefícios com o uso da norma 

Se usada, a norma assegura que os dirigentes poderão avaliar os riscos da 
TI para o negócio e aproveitar as oportunidades advindas com o uso da TL 
Entre os principais benefícios, a aplicação correta da governança corporativa 
de TI pode ajudar os dirigentes a garantir: 

□ O cumprimento das obrigações (regulamentares, legislativas, legais, 
contratuais) relativas ao uso aceitável da TI (sistemas inadequados po¬ 
dem expor os dirigentes ao risco de não cumprir com a legislação). 

□ Que o uso da TI contribua positivamente para o bom desempenho da 
organização através de: 

A Correta implementação e operação dos ativos de TI. 

A Clareza quanto à responsabilidade e obrigatoriedade em prestar con¬ 
ta, tanto quanto ao uso quanto à provisão da TI para atingir as metas 
da organização. 
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A 

A 

A 

A 

A 

A 

A 


Continuidade e sustentabilidade do negócio. 

Alinhamento da TI com as necessidades do negócio. 

Alocação eficiente de recursos. 

Inovação nos serviços, mercados e negócio. 

Boas práticas nos relacionamentos com as partes interessadas. 
Redução nos custos da organização. 

Concretização atual dos benefícios aprovados de cada investimen¬ 
to de TI. 


6 . 1.5 Considerações sobre a norma 

Esta norma não é objeto de certificação como a ISO 9001, 14000, 27001, 
etc. Entretanto, traz conceitos importantes sobre Governança de TI que po¬ 
dem ser úteis no entendimento, pela alta direção, de suas responsabilidades 
em relação à TI. 

Um modelo de arquitetura de direitos decisórios e de processos de TI pode 
ser desenvolvido com base nos seis princípios da norma. A questão é: como 
fazer chegar esses conceitos até a alta administração da empresa e fazer com 
que compreendam o papel reservado a eles? 

Aqui, novamente, aparece a discussão: quanto mais a organização for regu¬ 
lada externamente, maior será a necessidade por compliance e gestão de riscos 
de TI, facilitando, portanto, a chegada da mensagem na alta administração. 

Quanto menos regulação externa houver, mais difícil fica o entendimento 
da alta administração (pelo menos esta tem sido a experiência dos autores). A 
alternativa é sempre procurar o pessoal de auditoria interna ou externa para 
fazer um trabalho conjunto, onde os auditores apontam a necessidade da go¬ 
vernança e o responsável de TI entra com o modelo apropriado. 


6.2 CobiT 

6 . 2.1 Histórico do Modelo 

O CobiT (Control Objectives for Information and related Technology) foi cria¬ 
do em 1994 pela ISACF 28 a partir do seu conjunto inicial de objetivos de con- 


28 Information Systems Audit and Control Foundation, ligado à ISACA (ISAC Association) - acesso 
através do site http://www.isaca.org/ . 
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trole e vem evoluindo através da incorporação de padrões internacionais técni¬ 
cos, profissionais, regulatórios e específicos para processos de TI. Em 1998, foi 
publicada a sua segunda edição, contendo uma revisão nos objetivos de controle 
de alto nível e detalhados, e mais um conjunto de ferramentas e padrões para 
implementação. A terceira edição foi publicada em 2000 pelo IT Governance 
Institute (ITGI), órgão criado pela ISACA com o objetivo de promover um me¬ 
lhor entendimento e a adoção dos princípios de Governança de TI. 

O modelo evoluiu novamente em 2005 para a versão 4.0, através de prá¬ 
ticas e padrões mais maduros (totalmente alinhados a modelos como COSO, 
ITIL e ISO/IEC 17799) e em conformidade com as regulamentações, do foco 
mais acentuado na governança de TI nos níveis mais elevados e da ampliação 
da sua abrangência para um público mais heterogêneo (gestores, técnicos, 
especialistas e auditores de TI). 

Em 2007, houve uma atualização incremental (versão 4.1), cujo foco foi 
orientado a uma maior eficácia dos objetivos de controle e dos processos de 
verificação e divulgação de resultados. As definições dos objetivos de controle 
foram modificadas, para serem caracterizadas como diretrizes de práticas de 
gestão, mais orientadas à ação e consistentes em seu conteúdo escrito. 

O ano de 2012 foi marcado pelo lançamento do CobiT 5, que repre¬ 
sentou uma transformação estrutural do modelo para um fmmework de 
negócio completo para governança e gerenciamento da TI, integrando o 
conteúdo existente até o momento de várias outras publicações da ISACA, 
tais como CobiT 4.1, Val IT, Risk IT 29 , BMIS, ITAF, TGF e Board Briefing 
on IT Governance. Entre as principais evoluções que o CobiT 5 trouxe em 
relação à sua versão anterior, podem ser relacionadas: 

□ CobiT não é mais o acrônimo ou sigla para a expressão Control Ob- 
jectives for Information and related Technology , mas um nome que re¬ 
presenta uma forte marca no mercado de boas práticas de TI. 

□ Os “objetivos de controle” da versão 4.1 foram substituídos pelas 
“práticas-chave”. 

□ As “práticas de controle” da versão 4.1 agora são conhecidas como 
“atividades”. 


29 Os frameworks Val IT e Risk IT, que faziam parte do conteúdo da edição anterior deste livro, não 
foram trazidos para esta 4 a edição, uma vez que foram descontinuados pela ISACA (pois todo o seu 
conteúdo - inclusive práticas e processos - está integrado no CobiT 5). 
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□ Houve uma total reformulação do modelo de processos (que agora 
são 37 em vez dos 34 da versão 4.1). 

□ A estrutura do CobiT 5 está baseada em cinco princípios de go¬ 
vernança e gerenciamento empresarial da TI, substituindo as cinco 
áreas-foco de governança da versão 4.1. 

□ O foco do modelo está agora nos chamados “habilitadores” (um deles 
representa os processos de TI). 


6.2.2 Objetivos do modelo 

Segundo o CobiT 5, a informação é um recurso chave para qualquer 
empresa e a tecnologia tem um papel muito importante durante todo o seu 
ciclo de vida. A denominada TI (Tecnologia da Informação) tem se tornado 
cada vez mais um órgão vital nas empresas e em todos os ambientes sociais, 
públicos e de negócio. Nesse sentido, a adoção de uma abordagem onde 
tanto o gerenciamento quanto a governança da TI trabalham juntos visando 
o atingimento dos objetivos estratégicos tem sido cada vez mais valorizada 
nas empresas. 

O CobiT 5 endossa essa abordagem, uma vez que: 

□ Ajuda as empresas a atingirem seus objetivos de governança e geren¬ 
ciamento da TI em âmbito corporativo, assim como a otimizarem o 
valor da sua TI, balanceando os riscos versus os benefícios. 

□ Habilita a TI a ser gerenciada e governada de forma holística por toda 
a empresa (incluindo áreas de negócio, áreas funcionais da TI e partes 
interessadas internas e externas). 

□ Pode ser utilizado por empresas de qualquer natureza, mercado ou 
tamanho. 

O modelo do CobiT é genérico o bastante para representar todos os pro¬ 
cessos normalmente encontrados nas funções da TI e compreensível tanto 
para a operação como para os gerentes de negócios, pois cria uma ponte entre 
o que o pessoal operacional precisa executar e a visão que os executivos dese¬ 
jam ter para “governar” 30 . 


30 O CobiT está totalmente alinhado com a estrutura integrada para controles internos do COSO 
(Committee of Sponsoring Organizations of the Treadway Comission), que é amplamente aceito como 
estrutura de controle para governança corporativa e gestão de riscos. 
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6.2.3 Estrutura do modelo - Os princípios do CobiT 5 

A Governança de TI, quando implantada de forma integrada, permite que 
a empresa gerencie de forma eficiente seus investimentos em recursos tecno¬ 
lógicos e suas informações, transformando-as em maximização de benefícios, 
oportunidades de negócio e vantagem competitiva no mercado. 

Para o CobiT, a Governança e o Gerenciamento da TI empresarial estão 
sustentados por cinco princípios, conforme mostra a Figura 6.2: 



Figura 6.2 - Princípios-chave para a governança e o gerenciamento da TI empresarial, na visão do CobiT 

Fonte: ISACA (2012a) 


A seguir, será dada uma visão geral da estrutura do modelo, sob o enfoque 
de cada um dos seus princípios. 


6.2.3.1 Satisfazer as necessidades das partes interessadas 

Segundo o CobiT, toda empresa deve ter a geração de valor para as suas 
partes interessadas como um objetivo de governança e deve buscá-lo por meio 
da entrega de benefícios, otimizando os riscos e os custos dos recursos. A 
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governança está ligada às atividades de negociação e decisão, considerando as 
necessidades das várias partes interessadas envolvidas. 

Tais necessidades devem ser traduzidas em metas corporativas genéricas 31 , 
atingíveis e customizadas, metas relacionadas à TI e metas dos habilitadores 32 
de TL Para esta finalidade, o CobiT 5 propõe um “ sistema de metas em cas¬ 
cata ” que está ilustrado na Figura 6.3. 


Motivadores das Partes Interessadas 

(mudanças na estratégia, ambiente de negócios, regulamentos, 
novas tecnologias) 


influenciam 


Necessidades das Partes Interessadas 

(benefícios realizados, riscos otimizados, recursos otimizados) 


São 

desdobradas em - 


Utilizando 
o BSC 


Metas Corporativas 


São 

desdobradas em 


Criando o 
BSC de TI 


Metas Relacionadas à TI 


São 

desdobradas em 


Cultura, Ética, 
Comportamento ^ 

Estruturas 

Organizacionais 



Processos 


Serviços, 
Infraestrutura 
^ e Aplicações 

Pessoas, 
Habilidades e 
Competências 

Princípios, 
Políticas e 
Modelos 


Figura 6.3 - 0 sistema de metas em cascata do CobiT 
Adaptado de ISACA (2012a) 


31 Metas mais específicas aplicáveis a cada organização podem ser facilmente mapeadas para as 
metas genéricas propostas neste sistema. 

32 Habilitadores são fatores tangíveis e intangíveis que, individualmente e coletivamente, possuem 
influência sobre o funcionamento da Governança e do Gerenciamento da TI. 
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Alguns pontos merecem destaque especial em relação a este sistema de 
metas em cascata: 

□ As dimensões do Balanced Scorecara m são os critérios utilizados para 
agrupar as dezessete metas corporativas genéricas e as dezessete metas 
relacionadas à TI. 

□ Os três pontos indicados como necessidades das partes interessadas 
são considerados os principais objetivos de governança e estão rela¬ 
cionados com as metas corporativas conforme o grau de influência 
que estas têm sobre eles (primário ou secundário). 

□ Este modelo mostra como cada um dos habilitadores de TI (definidos 
mais adiante neste texto) são importantes para que as metas corpora¬ 
tivas sejam atingidas. 

□ O modelo fornece também exemplos de métricas que podem ser uti¬ 
lizadas para medir o atingimento de cada meta (como são exemplos, 
recomenda-se que cada empresa crie o seu próprio sistema de medi¬ 
ção, conforme a sua realidade interna). 

6.2.3.2 Cobrir a empresa de ponta a ponta 

O CobiT 5 não concentra o seu foco apenas na área de TI, sim na gover¬ 
nança e no gerenciamento da informação e da tecnologia relacionadas onde 
quer que estejam, cobrindo a empresa de ponta a ponta. Nesse sentido, inte¬ 
gra a governança empresarial de TI ao contexto da governança corporativa e 
endereça todos os serviços de TI e processos de negócio (internos e externos). 
Um sistema de governança é formado pelos seguintes componentes: 

□ Habilitadores da governança: recursos organizacionais utilizados 
para a governança, como princípios, frameworks , estruturas, proces¬ 
sos e práticas, através dos (ou para os) quais são conduzidas ações e 
atingidos objetivos. 

□ Escopo da governança: área que será efetivamente governada (desde 
um ativo tangível ou intangível até uma entidade ou mesmo a em¬ 
presa inteira. 


33 Perspectivas financeira, de clientes, de processos internos e de aprendizado e crescimento (mais 
detalhes sobre o BSC podem ser encontrados no Capítulo 12 deste livro). 
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□ Papéis, atividades e relacionamentos: definem as partes interessa¬ 
das envolvidas, o que elas fazem e como devem interagir dentro do 
escopo do sistema de governança. 


6.2.3.3 Aplicar um framework integrado único 

O CobiT 5 pode ser considerado um framework integrado único ou mes¬ 
mo um integrador entre os principais frameworks do mercado, em suas ver¬ 
sões mais atualizadas, uma vez que sua arquitetura é simples e serve como 
uma fonte consistente e integrada de diretrizes para a utilização desses mo¬ 
delos. O CobiT 5 está alinhado com frameworks importantes como ITIL, 
TOGAF, normas ISO, etc. e engloba também todo o conhecimento que 
estava espalhado por outros modelos da própria ISACA (tais como Val IT, 
Risk IT, BMIS etc.). 

Além disso, serve como uma estrutura base para todos os materiais de 
orientação, pois define um conjunto de habilitadores para governança e ge¬ 
renciamento e provê uma base bastante abrangente de boas práticas que po¬ 
derão ser utilizadas posteriormente na nossa avaliação. 


6.2.3.4 Permitir uma visão holística 

O CobiT 5 descreve sete categorias de habilitadores de TI , que possuem 
grande influência no sucesso da governança e do gerenciamento da TI: 

□ Princípios, políticas e estruturas , que auxiliam a traduzir comporta¬ 
mentos desejados em um guia prático para o dia a dia. 

□ Processos , que descrevem práticas e atividades para atingir objetivos 
específicos e também apoiam o atingimento das metas globais rela¬ 
cionadas à TI. 

□ Estruturas organizacionais, entidades de tomada de decisões-chave 
em uma empresa. 

□ Cultura, ética e comportamento dos envolvidos , geralmente muito 
subestimados como fatores críticos de sucesso para as atividades de 
governança e gerenciamento. 
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□ Informação gerada e utilizada pela empresa, que a mantém em funcio¬ 
namento e que, no nível operacional, é parte integrante do seu produto 
principal 34 . 

□ Serviços, infraestrutura e aplicações que apoiam a organização com 
processamento e serviços de TI 35 . 

□ Pessoas, habilidades e competências presentes nas pessoas e requeridas 
para a execução das atividades relacionadas ao escopo em questão 36 . 

Todos esses habilitadores possuem um conjunto de dimensões comuns, 
que fornece uma forma simples e estruturada para tratá-los, permite que as 
interações entre eles sejam gerenciadas (por mais complexas que sejam) e fa¬ 
cilita a obtenção de saídas robustas e bem estruturadas. A Figura 6.4 mostra 
como essas dimensões podem simplificar o entendimento dos habilitadores. 


Dimensões do Habilitador 



Gestão do Desempenho do Habilitador 


Figura 6.4 - Dimensões e gestão do desempenho dos habilitadores 
Adaptado de ISACA (2012a) 


34 Os sete critérios de informação presentes no CobiT 4.1 (Eficácia, Eficiência, Integridade, 
Confiabilidade, Disponibilidade, Confidencialidade e Conformidade) evoluíram para quinze metas 
do habilitador “Informação” no CobiT 5, agrupadas em três subdimensões da qualidade (intrínseca, 
contextuai e segurança/acessibilidade). 

35 Este habilitador abrange as categorias de Recursos de TI “Sistemas Aplicativos” e “Infraestrutura”, 
presentes no CobiT 4.1. 

36 Este habilitador abrange a categoria de Recursos de TI “Pessoas”, presente no CobiT 4.1. 
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□ Cada habilitador possui partes interessadas (internas e externas) que 
desempenham algum papel ativo ou simplesmente têm algum inte¬ 
resse nos seus resultados, cujas necessidades devem ser traduzidas em 
metas corporativas e gerenciadas apropriadamente. 

□ Em geral, as metas de cada habilitador são definidas em termos dos 
seus resultados esperados ou de sua própria utilização ou operação e 
refletem atributos de qualidade e segurança/acessibilidade. 

□ O ciclo de vida de um habilitador cobre desde a sua concepção até o 
momento em que sua utilização é descontinuada, e precisa ser ade¬ 
quadamente gerenciado. 

□ As boas práticas mostram exemplos ou sugestões de como imple¬ 
mentar cada habilitador e apoiam o atingimento das suas metas (este 
é um ponto onde recomenda-se a integração com outros padrões e 
modelos de boas práticas do mercado, conforme o contexto de cada 
habilitador). 

O desempenho dos habilitadores deve ser medido em função das saídas 
produzidas por eles (lag indicators ) e da maneira como estão funcionando 
(lead indicators) 07 . 


6.2.3.5 Separar governança de gerenciamento 

O CobiT 5 diferencia claramente os conceitos de governança e gerencia¬ 
mento, como disciplinas que envolvem diferentes tipos de atividades e estru¬ 
turas organizacionais, e que servem a propósitos distintos: 

□ Governança : assegura que as necessidades, condições e opções das 
partes interessadas sejam avaliadas para determinar objetivos corpora¬ 
tivos balanceados e acordados a serem atingidos, estabelecendo prio¬ 
ridades, tomando decisões e monitorando o desempenho e a confor¬ 
midade em relação à direção e aos objetivos acordados. 

A Em geral, é uma responsabilidade do corpo diretivo da empresa. 


37 Para os que conhecem o CobiT 4.1 , os conceitos desses indicadores estavam totalmente relacionados 
aos processos de TI. Já no CobiT 5, que está mais abrangente, os processos são apenas uma das sete 
categorias de habilitadores de TI. 
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□ Gerenciamento : planeja, constrói, executa e monitora atividades de 
forma alinhada com a direção estabelecida pelo grupo de governança, 
visando o atingimento dos objetivos corporativos. 

A Em geral, é uma responsabilidade da gerência executiva, sob a 
liderança do CEO da empresa. 

A criação de um sistema de governança efetivo requer que as disciplinas de 
governança e gerenciamento interajam de forma estruturada (os habilitadores 
relacionados na seção anterior podem ser um excelente ponto de partida para 
o estabelecimento dessas interações). 


6.2.4 O MODELO DE REFERÊNCIA DE PROCESSOS DO COBlT 5 

Como um dos passos mais importantes para uma boa governança, o CobiT 
5 sugere um modelo de referência que define e descreve processos, agrupan¬ 
do-os nas áreas-chave de governança e gerenciamento (ver Figura 6.5) 38 . 


Necessidades do Negócio 



Figura 6.5 - Áreas-chave e domínios de processos 
Adaptado de ISACA (2012a) 


38 Como se pode notar, a área-chave de Governança do CobiT 5 está diretamente relacionada aos 
requisitos da Norma ISO/IEC 38500. 
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A Figura 6.5 também introduz os cinco domínios de processos 39 do CobiT 5: 

□ Governança (EDM 40 ) : este domínio contém cinco processos de go¬ 
vernança, dentro dos quais são definidas práticas de avaliação, direção 
e monitoração. 

□ Alinhar, Planejar e Organizar (APO 41 ) : este domínio tem abrangên¬ 
cia estratégica e tática e identifica as formas através das quais a TI 
pode contribuir melhor para o atendimento dos objetivos de negócio, 
envolvendo planejamento, comunicação e gerenciamento em diver¬ 
sas perspectivas. 

□ Construir, Adquirir e Implementar (BAI 42 ): este domínio cobre 
identificação, desenvolvimento e/ou aquisição de soluções de TI 
para executar a estratégia de TI estabelecida, assim como a sua im¬ 
plementação e integração junto aos processos de negócio. Mudan¬ 
ças e manutenções em sistemas existentes também estão cobertas 
por este domínio, para assegurar a continuidade dos respectivos 
ciclos de vida. 

□ Entregar, Reparar e Suportar (DSS 43 ): este domínio cobre a entrega 
propriamente dita dos serviços requeridos, incluindo gerenciamento 
de segurança e continuidade, reparo de equipamentos e demais itens 
relacionados, suporte aos serviços para os usuários, gestão dos dados 
e da infraestrutura operacional. 

□ Monitorar, Avaliar e Medir (MEA 44 ): este domínio visa assegurar a 
qualidade dos processos de TI, assim como a sua governança e con¬ 
formidade com os objetivos de controle, através de mecanismos re¬ 
gulares de acompanhamento, monitoração de controles internos e de 
avaliações internas e externas. 

A Tabela 6.2, a seguir, mostra os 37 processos de TI relativos a cada um dos 
domínios do CobiT 5. 


39 Os domínios APO, BAI, DSS e MEA são evoluções dos domínios PO, Al, DS e ME do CobiT 4.1. 

40 A sigla “EDM” vem do inglês Evaluate, Direct and Monitor. 

41 A sigla “APO” vem do inglês Align, Ptan and Organise. 

42 A sigla “BAI” vem do inglês Build, Acquire and Implement. 

43 A sigla “DSS” vem do inglês Detiver, Service and Support. 

44 A sigla “MEA” vem do inglês Monitor, Evaluate and Assess. 
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Processos de TI 

EDM 
(Avaliar, 
Dirigir e 
Monitorar) 

• EDM01 -* Assegurar o estabelecimento e a manutenção do frameworkde Governança 

• EDM02 -*■ Assegurar a entrega dos benefícios 

• EDM03 -► Assegurar a otimização dos riscos 

• EDM04 -*■ Assegurar a otimização dos recursos 

• EDM05 -* Assegurar a transparência para as partes interessadas 

APO 

(Alinhar, Planejar e Organizar) 

• APO01 -*■ Gerenciar o framework de gestão de TI 

• APO02 -► Gerenciar a estratégia 

• APO03 -*■ Gerenciar a arquitetura corporativa 

• APO04 -» Gerenciar a inovação 

• APO05 -+• Gerenciar o portfólio 

• APO06 -*■ Gerenciar orçamento e custos 

• APO07 -► Gerenciar recursos humanos 

• APO08 -*■ Gerenciar relacionamentos 

• APO09 -» Gerenciar acordos de serviço 

• APOIO -» Gerenciar fornecedores 

• APO11 -* Gerenciar a qualidade 

• AP012 -*■ Gerenciar riscos 

• AP013 -*• Gerenciar a segurança 

BAI 

Construir, Adquirir e 
Implementar) 

• BAI01 -*■ Gerenciar programas e projetos 

• BAI02 -*■ Gerenciar a definição de requisitos 

• BAI03 -*■ Gerenciar a identificação e a construção de soluções 

• BAI04 -*■ Gerenciar disponibilidade e capacidade 

• BAI05 -*■ Gerenciar a habilitação da mudança organizacional 

• BAI06 -*■ Gerenciar mudanças 

• BAI07 -*■ Gerenciar o aceite e a transição das mudanças 

• BAI08 -*■ Gerenciar o conhecimento 

• BAI09 -*■ Gerenciar ativos 

• BA110 -*■ Gerenciar a configuração 

DSS 

(Entregar, 
Reparar e 
Suportar) 

• DSS01 -* Gerenciar operações 

• DSS02 -+ Gerenciar requisições de serviços e incidentes 

• DSS03 -» Gerenciar problemas 

• DSS04 -*• Gerenciar a continuidade 

• DSS05 -*• Gerenciar os serviços de segurança 

• DSS06 -*■ Gerenciar controles de processos de negócios 

MEA 

(Monitorar, 
Avaliar e Medir) 

• MEA01 -*• Monitorar, avaliar e medir o desempenho e a conformidade 

• MEA02 -*■ Monitorar, avaliar e medir o sistema de controles internos 

• MEA03 -*■ Monitorar, avaliar e medir a conformidade com requisitos externos 


Tabela 6.2 - Processos dos domínios do CobiT 
Adaptado de ISACA (2012a) 
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Cada um dos 37 processos de TI é descrito através de seus componentes 
inter-relacionados: 

□ Identificação do processo (código, nome, área-chave e domínio). 

□ Descrição do processo. 

□ Propósito geral do processo. 

□ Metas em cascata relacionadas (metas relacionadas à TI suportadas 
primariamente e métricas sugeridas para medi-las). 

□ Metas e exemplos de métricas específicas do processo. 

□ Matriz de responsabilidades (modelo RACI), associando os papéis às 
tarefas. 

□ Descrição detalhada das práticas do processo (para cada prática): 

A Título e descrição. 

A Entradas e saídas (com origens e destinos). 

A Detalhamento das atividades. 

□ Orientações relacionadas, referenciando outros modelos e padrões, 
além de documentação adicional. 

O Modelo de Referência de Processos do CobiT 5 sucede o Modelo de 
Processos do CobiT 4.1 e integra os modelos de processos Val IT e Risk IT, 
que foram descontinuados pela ISACA. 


6.2.5 Diretrizes de implementação 

A implementação das práticas do CobiT 5 é apoiada por um conjunto de 
diretrizes baseado em uma abordagem de ciclo de vida de melhoria contínua 
e em algumas premissas básicas que devem ser respeitadas: 

□ O contexto atual e a cultura da empresa devem ser levados em consi¬ 
deração, assim como os seus habilitadores e restrições. 

□ Deve ser criado um ambiente propício ao comprometimento de to¬ 
das as partes interessadas (principalmente as mais críticas), com es¬ 
truturas apropriadas para direcionamento, supervisão e suporte, em 
todos os níveis da organização. 
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□ É necessário reconhecer onde estão os pontos fracos (em inglês, pain 
points) no contexto da TI, assim como eventos externos ou internos 
que possam impactar a governança e/ou o gerenciamento da TI (tais 
como fusões, aquisições, reduções de investimentos, novos requisitos 
regulatórios ou de compliance, mudanças no mercado etc.). 

□ Viabilizar a mudança, buscando ultrapassar os focos de resistência 
humana, comportamental e cultural por meio de uma abordagem 
positiva sobre os benefícios da sua implementação para o interesse 
comum da empresa. 

□ O ciclo de vida de implementação pressupõe a existência de um pro¬ 
grama (não somente um projeto) de sete fases, que é sustentado de 
forma iterativa por uma abordagem consistente de governança e ge¬ 
renciamento. A Figura 6.6 mostra uma visão planificada desse ciclo 
de vida. 

□ Por fim, recomenda-se criar um business case que demonstre de que 
forma essa implementação trará valor para o negócio da empresa. 
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Figura 6.6 - Visão planificada do ciclo de vida de implementação 
Adaptado de ISACA (2012a) 


6.2.6 O MODELO DE CAPACIDADE DE PROCESSOS 

Uma das grandes mudanças do CobiT 5 em relação à sua edição anterior 
(4.1) é a adoção de um modelo de capacidade de processos, abandonando a 
visão de modelo de maturidade. Enquanto no CobiT 4.1 era possível gerar 
um Relatório de Perfil de Maturidade para uma empresa para identificar em 
quais atributos havia pontos fracos específicos que precisavam de melhorias, 
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no CobiT 5, para cada processo pode ser realizada uma avaliação para cada 
um de seus atributos de capacidade 45 . 

A abordagem inicial que deu origem a este modelo de capacidade foi in¬ 
troduzida no Process Assessment Model (PAM), publicado em 2011, cuja fi¬ 
nalidade era fornecer uma base para a avaliação dos processos de TI de uma 
organização, tendo como uma de suas referências principais a norma ISO/ 
IEC 15504 - Engenharia de Software - Avaliação de Processo. Esta publica¬ 
ção também foi revisada para adequação ao CobiT 5. 

A Tabela 6.3 mostra os seis níveis de capacidade que um processo pode 
atingir e os atributos de desempenho da capacidade para cada um desses níveis: 


Nível de 
Capacidade 

Descrição 

Atributos Genéricos de Capacidade 
de Processo 

Nível 0 (Processo 
Incompleto) 

0 processo não está implementado ou 
falha no atingimento de seu propósito. 
Neste nível, há pouca ou nenhuma 
evidência de qualquer atingimento 
sistemático do propósito do processo. 


Nível 1 (Processo 
Executado) 

0 processo implementado atinge o seu 
propósito. 

PAI .1 - Desempenho do Processo. 

Nível 2 (Processo 
Gerenciado) 

0 processo está implementado de forma 
gerenciada (planejada, monitorada e 
ajustada) e seus produtos de trabalho 
são estabelecidos, controlados e 
mantidos apropriadamente. 

PA2.1 - Gestão do Desempenho. 

PA2.2 - Gestão de Produtos de Trabalho. 

Nível 3 (Processo 
Estabelecido) 

0 processo está implementado 
utilizando um processo definido capaz 
de atingir os seus resultados esperados. 

PA3.1 - Definição do Processo. 

PA3.2 - Implantação do Processo. 

Nível 4 (Processo 
Previsível) 

0 processo opera dentro de limites 
definidos para atingir os seus resultados 
esperados. 

PA4.1 - Medição do Processo. 

PA4.2 - Controle do Processo. 

Nível 5 (Processo em 
Otimização) 

0 processo é continuadamente 
melhorado para atender aos objetivos 
de negócio atuais e projetos mais 
relevantes. 

PA5.1 - Inovação do Processo. 

PA5.2 - Otimização do Processo. 


Tabela 6.3 - Níveis de capacidade de processos do CobiT 
Adaptado de ISACA (2012a) 


45 Deve-se considerar que “Processos” é apenas um dos sete habilitadores de TI no contexto do 
CobiT 5, ou seja, para que se tenha uma ideia mais precisa da situação atual da governança em uma 
organização, deve-se olhar para todo o cenário de forma holística, e não somente para os processos. 
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Através deste modelo de capacidade, a gerência tem condições de: 

□ Mapear a situação atual da capacidade de cada processo. 

□ Estabelecer e monitorar passo a passo as melhorias dos processos 
rumo à estratégia da organização. 


6.2.7 A FAMÍLIA DE PRODUTOS DO COBlT 5 

Além do documento principal CobiT 5, que descreve o frameivork , há 
outros produtos 46 que complementam o seu conteúdo, cada um com um foco 
específico (ver site da ISACA - www.isaca.org), tais como: 

□ CobiT 5 Enablim Processes : guia de referência detalhado para os pro¬ 
cessos definidos no Modelo de Referência de Processos do CobiT 5. 

□ CobiT 5 Enablim Information -, guia de referência que fornece uma 
forma estruturada de pensar sobre questões de governança e gerencia¬ 
mento de informações em qualquer tipo de organização. 

□ CobiT 5 Implementation : fornece uma abordagem de boas práticas 
para implementar a Governança Corporativa de TI com base em um 
ciclo de vida de melhoria contínua adaptável às necessidades especí¬ 
ficas de cada empresa. 

□ CobiT 5 for Information Security . contempla as diretrizes específicas 
do modelo aplicáveis ao âmbito da segurança da informação, no sen¬ 
tido de assegurar a confidencialidade, a integridade e a disponibilida¬ 
de das informações. 

□ CobiT 5for Assurance : focaliza nas avaliações e fornece diretrizes deta¬ 
lhadas e práticas para os profissionais que asseguram a qualidade (por 
exemplo, auditores, equipes de compliance, reguladores, executivos) e 
outras partes interessadas, sobre como utilizar o CobiT 5 para supor¬ 
tar tais atividades. 

□ CobiT 5 for Risk \ contempla as diretrizes específicas do modelo apli¬ 
cáveis ao âmbito do gerenciamento de riscos. 


46 A ISACA cria permanentemente novos guias para trazer o conteúdo do CobiT 5, para o detalhamento 
de temas específicos até um nível considerado satisfatório. Para maiores detalhes, consulte a página da 
ISACA (www.isaca.org) na Internet. 
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□ CobiT 5 Assessment Pro'/ramme \ base para avaliar ou auditar os proces¬ 
sos de uma empresa em relação à governança e ao gerenciamento da 
TI e dos serviços relacionados. 


6.2.8 Aplicabilidade do modelo 

A partir do alinhamento com os requisitos de alto nível do negócio e da boa 
convivência com outros padrões e modelos de boas práticas existentes no mer¬ 
cado, o CobiT cobre todo o conjunto de atividades de TI, concentrando-se 
mais em “o que” deve ser atingido em vez de “como” atingir, em termos de 
governança, gestão e controle. Nesse sentido, recomenda-se que o CobiT seja 
utilizado no nível estratégico, com o objetivo de delinear uma estrutura de 
controle e gestão baseada em um modelo de processos que seja aplicável para 
toda a empresa. 

Entre as várias oportunidades de aplicação em uma organização, podem 
ser ressaltadas: 

□ Avaliação dos habilitadores 47 de TI : a grande abrangência do CobiT 
e o alto grau de padronização permitem a sua utilização como um 
checklist para avaliar os pontos fortes e os pontos fracos de todos os 
habilitadores de TI, servindo como subsídio para a proposição de 
ações de melhoria, visando uma estruturação eficaz da governança e 
do gerenciamento (tanto na forma de autoavaliações quanto na de 
avaliações externas). 

□ Atuação na governança em vários níveis : de acordo com ISACA 
(2009), o conceito de Governança Corporativa de TI possibilita a 
atuação com uma visão corporativa (tratando, por exemplo, ques¬ 
tões legais e/ou de compliancé), com a visão de cada entidade dentro 
da corporação (linhas de negócio, funções, unidades organizacionais 
- inclusive a área de TI) ou mesmo com a visão focada em ativos 
específicos, sejam eles tangíveis (pessoas, tecnologia, capital) ou in¬ 
tangíveis (processos, serviços, marcas, imagem, conhecimento etc.). 


47 Até a versão 4.1, era possível somente avaliar os processos de TI. Conforme já dito antes, com 
a versão 5, os processos correspondem a apenas uma das sete categorias de habilitadores de TI, o 
que permite que se tenha uma visão holística sobre todos os fatores que influenciam a governança e o 
gerenciamento da TI. 
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□ Implementação modular da Governança de TI : práticas e padrões re¬ 
lativos a habilitadores (tais como áreas e processos específicos) podem 
ser mapeados para os habilitadores do modelo (mesmo que com base 
em outros modelos, como ITIL, CMMI, PMBOK etc.), de forma 
a criar uma estrutura específica de governança e gestáo, reutilizando 
práticas, processos e padrões já existentes. 

□ Avaliação dos riscos operacionais de TI : os habilitadores podem ser 
avaliados em conjunto ou isoladamente, e as suas discrepâncias em 
relação às metas e boas práticas perante os riscos que podem repre¬ 
sentar para o negócio da empresa, em termos de sua probabilidade de 
ocorrência e da severidade do impacto. 

□ Realização de benchmarking , a existência de um modelo de avaliação 
padronizado para todos os habilitadores de TI permite que uma orga¬ 
nização possa montar uma estratégia baseada na sua situação atual em 
termos de Governança de TI, utilizando como parâmetros de compa¬ 
ração dados de outras empresas best-in-class ou padrões internacionais 
de mercado, e estabelecendo suas próprias metas de crescimento e 
melhoria contínua. 

□ Qualificação de fornecedores de TI : o modelo de capacidade de pro¬ 
cessos do CobiT pode ser utilizado como qualificador na contratação 
de serviços de TI, ou mesmo no estabelecimento de níveis de serviço 
dentro de uma organização. A grande vantagem da utilização deste 
modelo é a padronização, ou seja, a utilização dos mesmos critérios 
para avaliar processos (assim como todos os demais habilitadores) em 
diversas organizações. 

Como modelo de Governança de TI, o CobiT pode ser aplicado tanto 
em pequenas organizações como em grandes empresas de TI, desde que 
esteja consistente com os objetivos de negócio e com as suas estratégias 
relacionadas à TI. A implantação de padrões e boas práticas pode ser mais 
bem-sucedida se for aplicada como um conjunto de princípios e como um 
ponto de partida para a adaptação modelo de governança e gerenciamento 
de TI da empresa, em vez de uma solução pronta para todos os problemas. 
Apesar de permitir que uma organização construa uma estrutura completa 
e eficaz de governança e gerenciamento, o framework do CobiT pode ser 
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utilizado de forma gradual, em conformidade com um planejamento es¬ 
tratégico que estabeleça prioridades para a implementação ou melhoria dos 
processos de TI. 

Em relação ao público-alvo dentro de uma organização, o CobiT é apli¬ 
cável a todas as funções envolvidas na governança e no gerenciamento da 
informação e da tecnologia relacionada, nas quais a informação pode ser pro¬ 
cessada. Isso inclui a gestão executiva da corporação, os gestores de negócio, 
os gestores de TI e também os profissionais que atuam em verificações (como 
por exemplo auditores e áreas de garantia de qualidade). 


6.2.9 Benefícios do modelo 

A forma através da qual o CobiT está estruturado favorece muito o enten¬ 
dimento dos vários habilitadores de TI (inclusive dos processos) e, consequen¬ 
temente, fornece um excelente guia para a sua implementação ou melhoria nas 
organizações, assim como para a avaliação da capacidade atual dos processos 
existentes. A utilização sistemática do CobiT como um modelo de governança 
e gestão poderá trazer vários benefícios para uma organização, tais como: 

□ Maior assertividade na tomada de decisões acerca dos investimentos em 
iniciativas de TI, por conta de uma melhor visibilidade acerca do rela¬ 
cionamento entre as necessidades do negócio (das várias partes interes¬ 
sadas), as metas corporativas, as metas relativas àTI e os processos de TI. 

□ Responsabilidades e protocolos de comunicação bastante claros, tor¬ 
nando a circulação de informações mais direta e precisa entre as par¬ 
tes interessadas em vários níveis. 

□ Visão clara acerca da situação atual dos habilitadores de TI e de seus 
pontos de vulnerabilidade. 

□ Redução da exposição a riscos (obviamente, caso sejam tomadas ações 
de melhoria preventivas em relação aos pontos negativos identifica¬ 
dos na análise dos habilitadores). 

□ Maior solidez e assertividade no planejamento encadeado das ações 
de melhoria, devido ao entendimento das interdependências entre os 
habilitadores analisados, em relação à sua contribuição para as metas 
corporativas estabelecidas. 
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□ Alta visibilidade, por parte de todos os níveis da organização, acerca 
do impacto dos esforços de melhoria nos habilitadores de TI e dos 
seus reflexos nos processos de negócio e nas metas corporativas, atra¬ 
vés das medições de resultados e dos indicadores de desempenho. 

□ Redução dos custos operacionais e de propriedade do acervo de TI 
(aplicativos, infraestrutura). 

□ Melhoria da imagem perante os clientes, através do aumento do grau de 
satisfação e da confiabilidade em relação aos produtos e serviços de TI. 

Em suma, utilizando o CobiT, uma organização poderá estabelecer bases 
mais sólidas para melhor governança e gerenciamento das iniciativas de TI. 


6.2.10 Certificações relacionadas 

A ISACA oferece três níveis de certificação profissional, relacionados ao 
conhecimento e à proficiência na utilização do CobiT: 

□ CobiT 5 Foundation -, atesta que os profissionais certificados compre¬ 
endem os problemas de governança e gestão da TI das empresas e sa¬ 
bem como utilizar o CobiT para enfrentar e solucionar esses desafios. 

□ CobiT 5 Implementation : atesta que os profissionais certificados de¬ 
monstraram conhecimento sobre como o CobiT 5 pode ser adapta¬ 
do para atender às necessidades específicas de uma empresa, além de 
domínio da implementação da Governança Corporativa de TI com 
base em ciclo de melhoria contínua. 

□ CobiT 5 Assessor : direcionado a auditores internos e externos e a con¬ 
sultores de TI, atesta que os profissionais certificados demonstraram 
domínio sobre como realizar uma avaliação de capacidade de proces¬ 
so formal e sobre como ela pode ser utilizada para habilitar metas de 
negócio, priorizar iniciativas de melhoria e identificar oportunidades 
de melhoria da governança e do gerenciamento dos ativos de infor¬ 
mação e tecnologia. 

Informações mais completas sobre as certificações do CobiT 5 podem ser 
encontradas na página da ISACA (www.isaca.org). 
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6.3 AS CERTIFICAÇÕES DA ISACA 

Existem quatro programas avançados de certificação profissional, patro¬ 
cinados pela ISACA, relacionados aos preceitos do CobiT (todos os exames 
exigem comprovação de experiência anterior): 

□ CISA (Certiíied Information Systems Auditor) -, destinado a avaliar o 
grau de proficiência e excelência nas disciplinas de auditoria, controle 
e segurança em TI. Este exame tem sido considerado um dos mais 
eficazes instrumentos de certificação em âmbito global. 

□ CISM (Certified Information Security ManagerY . destinado aos pro¬ 
fissionais especialistas que trabalham no planejamento, no gerencia¬ 
mento, no acompanhamento e na execução de atividades relacio¬ 
nadas à segurança da informação em uma organização. Este exame 
avalia a visão global do profissional sobre o tema, com foco em cinco 
assuntos: governança de segurança da informação, gestão de riscos, 
gestão de programas de segurança da informação, gestão de segurança 
da informação e gestão de respostas a eventos. 

□ CGEIT (Certiíied in the Governance of Enterprise IT) : esta certifica¬ 
ção visa reconhecer os indivíduos que possuem conhecimentos, ex¬ 
periência e habilidades profissionais em nível necessário e suficiente 
para maximizar a contribuição que a TI oferece para o atendimento 
aos objetivos de negócio da organização e, ao mesmo, tempo, ge¬ 
renciar e mitigar os riscos inerentes à TI para o negócio. Este exa¬ 
me avalia a proficiência e experiência do profissional nos seguintes 
temas: framework de governança corporativa de TI, gestão estraté¬ 
gica, realização de benefícios, otimização de riscos e otimização de 
recursos. 

□ CRISC (Certified in Risk and Information Systems Controlh certifi¬ 
cação projetada para profissionais que têm experiência prática com 
identificação de risco, avaliação, resposta ao risco, monitoramento 
de riscos, projeto e implantação de controle em sistemas de infor¬ 
mação e manutenção e monitoramento de controles em sistemas de 
informação. 
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Para obtenção dessas certificações, os postulantes devem: 

□ Passar em um exame específico. 

□ Demonstrar a experiência e as qualificações profissionais requeridas, 
fornecendo as evidências de prática conforme o tipo de certificação. 

□ Aderir formalmente ao Código de Ética da ISACA. 

□ Aderir à política de educação profissional continuada da ISACA (que 
envolve uma quantidade mínima de horas anuais em treinamentos e 
atividades de contribuição à profissão). 

Para a manutenção do certificado, o postulante deverá evidenciar 120 ho¬ 
ras de CPE 48 ao longo de três anos (sendo no mínimo vinte horas de CPE a 
cada ano). Isso é demonstrado pela participação em atividades educacionais 
das quais participa e atividades que demonstrem a sua contribuição para a pro¬ 
fissão, como ministrar cursos no tema, participar em pesquisas da ISACA etc. 


48 Sigla para Continuing Professional Education. 
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De acordo com a ITIL, um serviço é um “meio de entregar valor aos clientes, 
facilitando o atingimento dos resultados que os clientes desejam, tirando deles 
a propriedade dos custos e riscos específicos”. Pela perspectiva do cliente, a cria¬ 
ção do valor de um serviço é uma função de duas variáveis: a utilidade (possui 
o desempenho desejado ou redução das restrições de desempenho) e a garantia 
(disponibilidade, capacidade, continuidade e segurança suficientes para o uso). 

O gerenciamento de serviços pode ser definido como “um conjunto de 
capacitações organizacionais especializadas para fornecer valor aos clientes na 
forma de serviços”, ou seja, de transformar recursos em serviços valiosos. Tais 
capacitações podem ser vistas como processos e funções para gerenciar servi¬ 
ços ao longo do seu ciclo de vida. 

Neste capítulo, são apresentados, de forma resumida, os princípios e proces¬ 
sos de dois modelos que têm sido utilizados em todo o mundo como base para 
a implementação de boas práticas de Gerenciamento de Serviços de TI: a ITIL 
(biblioteca de melhores práticas) e a ISO/IEC 20000 (norma aplicável a orga¬ 
nizações que fornecem serviços de TI). Além disso, são mencionados também 
o CMMIfor Services, o MPS-BRpara Serviços, o USMBOK {UniversalService 
Management Body of Knoivledgê) e MOF {Microsoft Operations Framework ). 


7.1 ITIL 

7.1.1 Histórico do modelo 


A ITIL {Information Technology Infrastructure Library) foi desenvolvida 
pelo CCTA {Central Computer and Telecommunications Agency) no final dos 
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anos 80, a partir de uma encomenda do governo britânico, que não estava 
satisfeito com o nível de qualidade dos serviços de TI a ele prestado. Neste 
cenário, foi solicitado o desenvolvimento de uma abordagem de melhores 
práticas para gerenciar a utilização eficiente e responsável dos recursos de TI, 
independentemente de fornecedores e aplicável a organizações com necessida¬ 
des técnicas e de negócio distintas. Em abril de 2001, o CCTA foi incorpora¬ 
do ao OGC 49 (Office of Government Commerce ), que era na época o organismo 
responsável pela evolução e divulgação da ITIL. 

A versão 3 da ITIL (denominada V3), lançada em maio de 2007, repre¬ 
sentou uma grande evolução em relação à versão anterior, por organizar os 
processos de gerenciamento de serviços em uma estrutura de ciclo de vida de 
serviço. Além disso, a ITIL V3 demonstrava a maturidade que a disciplina de 
gerenciamento de serviços de TI adquiriu ao longo do tempo, trazendo e en¬ 
fatizando conceitos como integração da TI ao negócio, portfólios dinâmicos 
de serviços e mensuração do valor do negócio, e fornecendo uma base sólida 
para a convergência com outros padrões e modelos de gestão e governança, 
tais como ISO/IEC 20000, CobiT, CMMI, PMBOK, eSCM-SP etc. 

Entre as extensões que a ITIL V3 trouxe em relação à versão anterior, estão 
estratégias de serviços para modelos de sourcing e de compartilhamento de 
serviços, abordagens de retorno sobre o investimento (ROI) para serviços, 
práticas de desenho de serviços, um sistema de gerenciamento de conheci¬ 
mento sobre os serviços e o gerenciamento de requisições. 

Foi publicada pelo TSO 50 , em julho de 2011, uma atualização da ITIL 
V3 (denominada “ITIL 2011”), composta por mudanças relativamente leves, 
visando sobretudo: 

□ Corrigir alguns erros e inconsistências identificados no texto, nas fi¬ 
guras e nos relacionamentos entre os cinco livros. 

□ Incorporar sugestões de melhoria e soluções de problemas apresenta¬ 
das pela comunidade (usuários, fornecedores e instrutores), analisa¬ 
das e recomendadas pelo Comitê de Controle de Mudanças e apro¬ 
vadas pela OGC, no sentido de aumentar a clareza, a consistência, a 
navegação pelo conteúdo, a precisão e a abrangência. 

49 O OGC é um órgão independente subordinado à Secretaria-Chefe do Tesouro britânico, focado na 
melhoria dos processos de contratação e gestão de serviços privados pelo setor público. Em junho de 
2010, o Cabinet Office assumiu as funções de melhores práticas de gestão do OGC. 

50 The Stationery Office, a editora dos volumes da ITIL, vinculada ao The Cabinet Office. 
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□ Revisar o livro de Estratégia de Serviço e o Glossário de Termos 
para tornar a explicação de alguns conceitos mais clara, concisa e 
acessível. 

Atualmente, a propriedade e a comercialização deste portfólio de melhores 
práticas pertence à AXELOS, a primeira joint venture (formada pelo governo 
inglês e pela empresa Capita) focada no fornecimento de soluções integradas 
de suporte a serviços e outsourcing, com base em capital intelectual governa¬ 
mental (normas e padrões profissionais). 


7.1.2 Objetivos do modelo 

A ITIL é um agrupamento das melhores práticas utilizadas para o geren¬ 
ciamento de serviços de tecnologia de informação de alta qualidade, obtidas 
em consenso após décadas de observação prática, pesquisa e trabalho de pro¬ 
fissionais de TI e processamento de dados em todo o mundo. Devido à sua 
abrangência e profundidade, a ITIL tem se firmado continuamente como um 
padrão mundial de fato para as melhores práticas para o gerenciamento de 
serviços de TI. 

Como um framework , o principal objetivo da ITIL é prover um conjun¬ 
to de práticas de gerenciamento de serviços de TI testadas e comprovadas 
no mercado (organizadas segundo uma lógica de ciclo de vida de serviços), 
que podem servir como balizadoras, tanto para organizações que já possuem 
operações de TI em andamento e pretendem empreender melhorias, quanto 
para a criação de novas operações. A adoção das práticas da ITIL pretende 
levar uma organização a um grau de maturidade e qualidade que permita o 
uso eficaz e eficiente dos seus ativos estratégicos de TI (incluindo sistemas de 
informação e infraestrutura de TI), sempre com o foco no alinhamento e na 
integração com as necessidades dos clientes e usuários. 

A ITIL V3 (e, posteriormente, a ITIL 2011), com sua abordagem de ciclo 
de vida, permite que se tenha uma visão do gerenciamento de serviços pela 
perspectiva do próprio serviço, em vez de focar em cada processo ou prática 
por vez. Esta característica realça mais um importante objetivo, que é men¬ 
surar e gerenciar o valor que os serviços de TI efetivamente adicionam ao 
negócio. 

Nesta edição, faremos referência à ITIL 2011 simplesmente como “ITIL”. 



228 Implantando a Governança de TI - 4 a edição 


7.1.3 Estrutura do modelo 

7.1.3.1 Visão geral do modelo 

A ITIL pode ser considerada uma fonte de boas práticas utilizada pelas 
organizações para estabelecer e melhorar suas capacitações em gerenciamento 
de serviços. 

O núcleo da ITIL é composto por cinco publicações (conforme mostra a 
Figura 7.1), cada uma delas relacionada a um estágio do ciclo de vida do ser¬ 
viço, contendo orientações para uma abordagem integrada de gerenciamento 
de serviços 51 : 



Melhoria 
Contínua de 
Serviço 



Figura 7.1 - 0 núcleo da ITIL 
Adaptado de The Cabinet Office (2011 a) 


51 Em conformidade com os requisitos da norma ISO/IEC 20000. 
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□ Estratégia de Serviço : orienta sobre como visualizar o gerenciamen¬ 
to de serviços náo somente como uma capacidade organizacional, e 
sim como um ativo estratégico, e descreve os princípios inerentes à 
prática desta disciplina que são úteis para criar políticas, diretrizes e 
processos de gerenciamento de serviços ao longo do ciclo de vida de 
serviço. Entre os tópicos abordados nesta publicação, estão a criação 
de valor através dos serviços, os ativos de serviço, provedores e tipos 
de serviços, gerenciamento financeiro, portfólio de serviços, desen¬ 
volvimento organizacional, riscos estratégicos etc. 

□ Desenho de Serviço : fornece orientação para o desenho e desenvol¬ 
vimento dos serviços e das práticas de gerenciamento de serviços, 
detalhando aspectos do gerenciamento do catálogo de serviços, do 
nível de serviço, da capacidade, da disponibilidade, da continuidade, 
da segurança da informação e dos fornecedores, além de mudanças 
e melhorias necessárias para manter ou agregar valor aos clientes ao 
longo do ciclo de vida de serviço. 

□ Transição de Serviço : orienta sobre como efetivar a transição de ser¬ 
viços novos e modificados para ambientes operacionais gerenciados, 
detalhando os processos de planejamento e suporte à transição, ge¬ 
renciamento de mudanças, gerenciamento da configuração e dos ati¬ 
vos de serviço, gerenciamento da liberação e da distribuição, teste e 
validação de serviço, avaliação e gerenciamento do conhecimento. 

□ Operação de Serviço : descreve a fase do ciclo de vida do gerencia¬ 
mento de serviços que é responsável pelas atividades do dia a dia, 
orientando sobre como garantir a entrega e o suporte a serviços de 
forma eficiente e eficaz em ambientes operacionais gerenciados, e de¬ 
talhando os processos de gerenciamento de eventos, incidentes, pro¬ 
blemas, acesso e de cumprimento de requisições. 

□ Melhoria Contínua de Serviço : orienta, através de princípios, práticas 
e métodos de gerenciamento da qualidade, sobre como fazer siste¬ 
maticamente melhorias incrementais e de larga escala na qualidade 
do serviço, nas metas de eficiência operacional, na continuidade do 
serviço etc., com base no modelo PDCA (Plan-Do-Check-Aci). 

Os processos da ITIL encontram-se distribuídos entre os cinco estágios, con¬ 
forme a Tabela 7.1. 
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Estágios 

Processos 

Funções 

Estratégia de 
Serviço 

- Gerenciamento Estratégico para Serviços de TI 

- Gerenciamento Financeiro de TI 

- Gerenciamento do Portfólio de Serviços 

- Gerenciamento da Demanda 

- Gerenciamento do Relacionamento com o Negócio 


Desenho de 
Serviço 

- Coordenação do Desenho 

- Gerenciamento do Catálogo de Serviços 

- Gerenciamento do Nível de Serviço 

- Gerenciamento da Capacidade 

- Gerenciamento da Disponibilidade 

- Gerenciamento da Continuidade do Serviço 

- Gerenciamento da Segurança da Informação 

- Gerenciamento de Fornecedores 


Transição de 
Serviço 

- Planejamento e Suporte à Transição 

- Gerenciamento de Mudanças 

- Gerenciamento de Ativos de Serviço e da Configuração 

- Gerenciamento da Liberação e Distribuição 

- Validação e Teste do Serviço 

- Avaliação de Mudança 

- Gerenciamento do Conhecimento 


Operação de 
Serviço 

- Gerenciamento de Eventos 

- Gerenciamento de Incidentes 

- Cumprimento de Requisições 

- Gerenciamento de Problemas 

- Gerenciamento do Acesso 

- Central de Serviços 

- Gerenciamento Técnico 

- Gerenciamento das 

Operações de TI 

- Gerenciamento de Aplicações 

Melhoria 
Contínua de 
Serviço 

- Processo de Melhoria em 7 Passos 



Tabela 7.1 - Processos e funções da ITIL 


A seguir, descreveremos sucintamente alguns dos aspectos importantes de 
cada estágio do ciclo de vida de serviço, na visão da ITIL. 


7.1.3.2 Estratégia de Serviço 

Esta publicação define os princípios básicos que norteiam o gerenciamento 
de serviços, mostrando como uma organização pode transformá-lo em um 
ativo estratégico e orientando como esta pode operar e crescer com sucesso a 
longo prazo. Algumas questões comuns relacionadas a como implementar o 
gerenciamento de serviços são abordadas, tais como: 

□ Quais serviços oferecer e para quem? 

□ Como se diferenciar dos competidores? 
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□ De que forma é possível criar o conceito de valor de serviço, fazendo-o 
circular efetivamente entre os grupos interessados e os clientes? 

□ Como gerenciar os aspectos financeiros dos serviços? 

□ Como definir a qualidade do serviço e como melhorá-la? 

□ Como alocar recursos de forma eficiente através de um portfólio de 
serviços, e como resolver conflitos de demanda entre eles? 

7.1.3.2.1 Conceitos e princípios da Estratégia de Serviço 

Segundo a ITIL, uma estratégia consiste em um plano que mostra como 
uma organização atingirá um conjunto de objetivos. Especificamente neste 
caso, uma estratégia de serviço deve definir como um provedor utilizará seus 
serviços para potencializar os resultados de negócio de seus clientes, ao mes¬ 
mo tempo em que viabiliza o atingimento de seus próprios objetivos. Neste 
sentido, a escolha da estratégia precisa considerar o balanceamento entre de¬ 
cisões de negócio tais como: 

□ Focar no futuro ou no presente? 

□ Investir na eficiência operacional ou buscar vantagens competitivas 
por meio de melhorias nas funcionalidades dos serviços? 

□ Buscar valor imediatamente após a inovaçáo ou durante a operação 
contínua? 

Outro ponto crucial para a definição da estratégia é a identificação e a qua¬ 
lificação adequada dos clientes do serviço, assim como de suas necessidades e 
do que ele espera como resultado, o que remete ao conceito de valor . 

O valor de um serviço é o grau em que as expectativas dos clientes são atendi¬ 
das, e pode ser definido como uma função de duas variáveis: a utilidade (ou seja, 
a capacidade de atender às necessidades dos clientes e de minimizar as suas restri¬ 
ções) e a garantia (que está relacionada ao atendimento dos requisitos de dispo¬ 
nibilidade, desempenho, continuidade e segurança estabelecidos pelos clientes). 

Uma outra forma de definir valor pode ser uma função de três variáveis 
que precisam ser corretamente compreendidas e tratadas: os resultados de ne¬ 
gócios atingidos, as preferências dos clientes e a sua percepção sobre o que foi 
entregue pelo serviço, geralmente medida na forma de um grau de satisfação. 
Um serviço pode ser considerado um sistema fechado (no qual os resultados 
têm influência na sua realimentação). 
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Recursos e capacitações sáo considerados ativos de serviço de uma organi¬ 
zação e constituem a base para a criação de valor para o serviço. Como recur¬ 
sos, podem ser considerados itens como pessoas, informação, aplicações, in- 
fraestrutura e capital financeiro. Capacitações são desenvolvidas ao longo do 
tempo e podem incluir gerenciamento, organização, processos, conhecimento 
e pessoas. Os ativos de serviço contribuem para a potencialização dos ativos 
dos clientes, e ambos, quando formam uma base para formação de compe¬ 
tências chaves, para um desempenho diferencial ou para sustentar alguma 
vantagem competitiva, podem ser chamados de ativos estratégicos . 

AITIL considera que os provedores de serviços podem ser internos (áreas da 
própria organização, menos arriscadas e flexíveis), unidades de serviços compar¬ 
tilhados (risco e flexibilidade médios) ou externos (mais arriscados e flexíveis). As 
estruturas de serviço evoluíram da cadeia de valor básica para o de rede de valor , 
incorporando relacionamentos com fornecedores substitutos e complementares, 
além dos usuais entre o fornecedor, o provedor de serviço, o negócio e o cliente. 

Adicionalmente, a estratégia precisa considerar os aspectos financeiros da 
prestação do serviço e estar aderente ao padrão de departamentalização da 
empresa (por função, produto, mercado/cliente, geografia, processo etc.), as¬ 
sim como à cultura e ao estilo de gestão organizacional dominante na empre¬ 
sa, pois ele poderá ser crucial na concepção da estrutura organizacional mais 
adequada para o serviço. Estes estilos podem ser representados em estágios 
(similares a níveis de maturidade): 

□ 1 - Rede : entrega de serviços rápida, informal e sob demanda (o de¬ 
safio é a liderança). 

□ 2 - Diretivo : equipe habilidosa em gestão para dirigir a estratégia e 
gerentes com responsabilidades funcionais (o desafio é a autonomia). 

□ 3 - Delegação : mais poder para os gerentes (o desafio é o controle). 

□ 4 - Coordenação : uso de sistemas formais para melhorar a coordena¬ 
ção (o desafio é a burocracia). 

□ 5 - Colaboração : Forte sintonia com o negócio, maior flexibilidade, 
com gerentes altamente habilitados em trabalho de equipe e resolu¬ 
ção de conflitos. 

Ainda falando de organização, um último ponto de atenção é a estratégia 
de sourcing (caso esta seja uma possibilidade). Neste sentido, deve-se definir 
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o que terceirizar, qual(is) estrutura(s) de sourcing a ser(em) utilizada(s) (in- 
sourcing, serviços compartilhados, full outsourcing , contrato único com sub¬ 
contratados, consórcio, outsourcing seletivo), se haverá vários fornecedores, 
quais seráo as interfaces, os papéis e as responsabilidades, os fatores críticos de 
sucesso e o modelo de governança a ser adotado 52 . 


7.1.3.2.2 As etapas da definição dos serviços 

AITIL considera que sáo necessários oito passos para que um serviço possa 
ser concebido e definido em seus aspectos relevantes: 

□ Definir o mercado e identificar os clientes : quem sáo os clientes que têm 
interesse e condições de comprar o serviço, e para os quais o provedor 
está preparado legalmente e em termos de infraestrutura logística para 
entregá-lo? 

□ Compreender os clientes em termos dos resultados de negócio espe¬ 
rados, das suas preferências, percepções, assim como de seus ativos e 
suas restrições. 

□ Quantificar os resultados de forma clara e mensurável. 

□ Classificar e visualizar o serviço , buscando identificar “arquétipos” de 
serviços e ativos de clientes que possam revelar padrões de demandas 
e de comportamento para a prestação dos serviços 53 . 

□ Compreender as oportunidades (espaços de mercado) que podem 
existir nas “entrelinhas” da prestação desse serviço. 

□ Definir os serviços com base nos resultados esperados em termos de 
utilidade e garantia. 

□ Criar modelos para os serviços que descrevam a estrutura (itens de 
configuração e seus relacionamentos) e a dinâmica dos serviços e 
que possam ser utilizados como templates ou blueprints para futuros 
serviços. 

□ Definir unidades e pacotes para os serviços que permitam maior flexi¬ 
bilidade para a combinação das funcionalidades dos serviços. 


52 Neste ponto, a ITIL recomenda a ISO/IEC 20000. 

53 Esta pode ser uma técnica interessante para conceber futuros Portfólios e Catálogos de Serviços. 
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7.1.3.2.3 Os processos da Estratégia de Serviço 

Além do desenvolvimento da estratégia descrito anteriormente, são cinco 
os processos de gerenciamento de serviços que fazem parte do escopo da es¬ 
tratégia do serviço: 

□ Gerenciamento Estratégico para Serviços de TI : visa garantir que a 
estratégia para os serviços de TI seja definida, mantida e tenha seus 
objetivos atingidos. Para tal, auxilia a definir critérios e mecanismos 
para estabelecer os serviços mais adequados para atender aos requi¬ 
sitos do negócio, assim como a forma mais efetiva de gerenciá-los. 
Envolve a análise do ecossistema onde organização provedora de servi¬ 
ços se encontra, visando identificar e gerir oportunidades e restrições 
para a entrega dos serviços, criando planos estratégicos para tratá-las e 
desdobrando-os em planos táticos e operacionais nos quais cada parte 
interessada possa atuar. 

□ Gerenciamento do Portfólio de Serviços : método que visa governar 
os investimentos em gerenciamento de serviços através da empresa 
e gerenciá-los para que adicionem valor ao negócio 54 . Este processo 
estabelece que há duas categorias de serviços: os serviços de negócio 
(definidos pelo próprio negócio) e os serviços de TI (fornecidos pela 
TI ao negócio, mas que esse não reconhece como dentro de seus 
domínios). Embora a linha entre esses dois portfólios de serviços 
seja tênue, ambos podem ser gerenciados individualmente (depen¬ 
dendo da perspectiva de cada cliente), mas sempre considerando as 
inter-relações existentes. Este processo tem como etapas a definição 
do inventário dos serviços, a análise da viabilidade das iniciativas 
de serviços, a aprovação dessas iniciativas e a abertura do projeto de 
desenho ou redesenho dos serviços visando a sua incorporação ao 
Catálogo de Serviços. A Figura 7.2 mostra os principais elementos 
desta relação 55 . 


54 Os métodos de gerenciamento de portfólio de serviços, projetos e de TI são técnicas que viabilizam 
a governança. As diferenças entre eles estão nos detalhes de implementação. 

55 O Pipeline de Serviços contém os serviços que estão em desenvolvimento para um determinado 
cliente ou espaço de mercado, prestes a serem liberados pelo processo de Transição de Serviço. 
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Portfólio de Serviços 
Descrição 

Proposição de Valor 
Business Cases 
Prioridades 
Riscos 

Ofertas e Pacotes 
Custo e preço 

V 



Pipeline 

de 

Serviços 


Catálogo(s) de Serviço 
Serviços 

Produtos suportados 
Políticas 

Procedimentos de pedidos e requisições 
Condições e termos de suporte 
Pontos de entrada e escalonamentos 
Precificação e cobrança 


Figura 7.2 - Elementos do Portfólio de Serviços e do Catálogo de Serviços 
Adaptado de The Cabinet Office (2011 a) 


□ Gerenciamento Financeiro : visa gerenciar o ciclo financeiro do 
Portfólio de Serviços de TI de uma organização, de forma a pro¬ 
ver a sustentação econômica necessária para a execução dos seus 
serviços. Conceitos e métodos efetivos, tais como valorização de 
serviços, modelagem da demanda e otimização do portfólio e do 
fornecimento de serviços, são fundamentais para que seja possível 
a quantificação do valor dos serviços de TI e dos ativos envolvidos 
na prestação desses serviços, assim como para que o planejamen¬ 
to financeiro seja confiável. As atividades relacionadas à contabi¬ 
lização dos custos dos serviços devem assegurar a conformidade 
com os aspectos regulatórios aos quais a organização está sujeita. 
Questões como a estrutura de custos a ser adotada (centro de cus¬ 
tos, de lucro, de resultado etc.) e a opção pela cobrança (ou não) 
são decisões chaves a serem tomadas pelo gestor de serviços. O 
Retorno sobre o Investimento (ROI) recebe atenção especial na 
ITIL, como uma medida da habilidade de utilizar os ativos para a 
geração de valor adicional, ou seja, como uma forma de justificar 
o investimento em serviços. O ROI pode ser calculado de for¬ 
ma pré-programada, pós-programada (retroativa) ou mesmo para 
identificar necessidades do negócio que dependem do gerencia¬ 
mento de serviços. 

□ Gerenciamento da Demanda : visa gerenciar de forma síncrona os ci¬ 
clos de produção dos serviços (que consomem demanda) e os ciclos 
de consumo dos serviços (que geram mais demanda). Por exemplo, 












236 Implantando a Governança de TI - 4 a edição 


o aumento da quantidade de funcionários do cliente certamente in¬ 
tensificará a atividade do negócio, o que poderá acarretar em cresci¬ 
mento da demanda de incidentes e requisições de serviços. A análise 
da dinâmica do negócio poderá permitir o estabelecimento de pa¬ 
drões de atividades de negócio e de perfis de usuários, que podem ser 
combinados para a composição de pacotes de serviços customizados. 
Por exemplo, pode haver um pacote específico de serviços para exe¬ 
cutivos seniores que viajam muito, necessitam fortemente de assis¬ 
tência técnica e precisam ter altíssima disponibilidade 24 horas por 
dia para os assuntos de negócio. Esses conceitos têm sido bastante 
utilizados por provedores de serviços que oferecem soluções de full 
outsourcing de TI a seus clientes. 

□ Gerenciamento do Relacionamento com o Negócio 56 : visa gerenciar 
as relações entre uma organização provedora de serviços e seus clien¬ 
tes, de forma a permitir um entendimento adequado das suas neces¬ 
sidades e o fornecimento de serviços que estejam alinhados com as 
suas expectativas. Envolve a preocupação constante com a medição 
da satisfação dos clientes, com a elicitação de requisitos de negócio 
para serviços novos ou modificados e com quaisquer aspectos que 
possam influenciar o relacionamento existente. 


7.1.3.2.4 A implementação da estratégia no ciclo de vida do serviço 

A Estratégia de Serviço está no coração do ciclo de vida do serviço, repre¬ 
sentando a grande fonte de requisitos para todas as demais disciplinas que a 
implementam. A melhoria contínua do serviço fornece realimentação para 
todas as demais disciplinas, através das suas medições e avaliações. A Figura 
7.3 ilustra esta inter-relação entre as disciplinas da ITIL: 


56 Este processo possui uma correspondência direta com um dos processos existentes na norma ISO/ 
IEC 20000. 
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Figura 7.3 - Sistema fechado de planejamento e controle para a estratégia 
Adaptado de The Cabinet Office (2011 a) 


A estratégia, entretanto, deve ser implementada dentro do espaço de solu¬ 
ções delimitado pelas restrições impostas pelo negócio, tais como utilidade, 
garantia, capacidade máxima, preço, questões de licenciamento, padrões e 
regulações, recursos, valores morais e éticos etc. 

Aspectos tecnológicos também são importantes no desenho da estratégia, 
notadamente as necessidades de automação dos serviços, as interfaces entre 
os serviços habilitadas ou não por TI (desde processos manuais até canais de 
autoatendimento) e as ferramentas a serem utilizadas (tais como simuladores, 
modelos analíticos etc.). 


7.1.3.3 Desenho de Serviço 

Este estágio do ciclo de vida tem como foco o desenho e a criação de ser¬ 
viços de TI cujo propósito será realizar a estratégia concebida anteriormente. 
Através do uso das práticas, processos e políticas de TI vigentes, os serviços 
devem ser construídos de forma a assegurar a qualidade da entrega, a satisfação 
dos clientes, a eficiência dos custos e a facilidade de colocá-los em produção. 
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A ITIL define o Desenho de Serviço como “o desenho de serviços de TI 
apropriados e inovadores, incluindo suas arquiteturas, processos, políticas e 
documentação, para atender aos requisitos do negócio atuais e futuros”. 


7.1.3.3.1 Aspectos básicos do Desenho de Serviço 

Esta publicação descreve os princípios e fundamentos básicos do Desenho 
de Serviço, abordando cinco aspectos importantes que precisam ser conside¬ 
rados neste momento: 

□ O desenho de um novo serviço ou a alteração de um serviço existente 
deve ser encarado como o projeto de uma solução completa , com 
alto grau de aderência aos requisitos estabelecidos pelo negócio. Tais 
requisitos, assim como todos os recursos e capacitações necessárias 
para o serviço, devem estar de acordo com a estratégia estabelecida 
pela organização. 

□ Desenhar sistemas e ferramentas de gerenciamento (principalmente 
o Portfólio de Serviços), para que sejam capazes de apoiar os serviços 
em todos os momentos do ciclo de vida. 

□ Desenhar as arquiteturas tecnológicas e de gestão (serviços, apli¬ 
cações, dados/informação, infraestrutura e ambiente) para que te¬ 
nham as capacitações necessárias para operar os serviços de forma 
consistente. 

□ Desenhar os processos de TI e de Gerenciamento de Serviços, as¬ 
sim como papéis, responsabilidades e habilidades relacionados, 
para que sejam capazes de operar, apoiar e manter os serviços, 
assim como criar ferramentas que permitam a integração entre 
organizações. 

□ Desenhar métricas e métodos para medição da qualidade do processo 
de desenho do serviço, em termos do seu progresso, conformidade 
(com requisitos corporativos, de governança, regulação), eficácia e 
eficiência. 

Recomenda-se que os planos para o desenho, a transição e a operação des¬ 
ses aspectos incluam abordagens para análise de impacto técnico, comercial e 
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organizacional, gerenciamento de riscos, da comunicação, empacotamento e 
critérios de aceitação a serem aplicados sobre a entrega do serviço, assim como 
influências externas de outros modelos de referência (CobiT, CMMI, ISO 
27001, ISO 9001, ISO/IEC 20000 etc.). 

Após o desenho do serviço, algumas atividades são necessárias ainda antes 
do início do estágio de Transição do Serviço. Caso haja envolvimento de ou¬ 
tros fornecedores, é importante avaliar soluções alternativas e providenciar a 
obtenção da solução escolhida. O projeto (ou programa) de desenvolvimento 
da solução de serviço deve considerar atividades de criação, ajuste ou reutili¬ 
zação dos componentes do serviço. 

Neste sentido, a utilização de abordagens como SOA (Service OrientedAr- 
cbitecturé) e BSM (Business Service Management) pode ser importante para 
desenvolver serviços de TI flexíveis e reutilizáveis, que possam ser comparti¬ 
lhados por várias áreas de negócio, e para garantir que esses componentes de 
TI estejam integrados aos objetivos do negócio. O modelo a ser utilizado para 
o desenho e desenvolvimento do serviço depende da escolha do modelo de 
entrega do serviço 57 . 

7.1.3.3.2 Os processos do Desenho de Serviço 

O estágio de Desenho de Serviço é suportado por um conjunto de oito 
processos de Gerenciamento de Serviços, descritos a seguir nesta seção. A Fi¬ 
gura 7.4 mostra como esses processos se encaixam dentro de uma visão mais 
abrangente do Desenho de Serviço. 


57 Tais modelos envolvem estratégias de sourcing, como insourcing, outsourcing, co-sourcing, 
multisourcing, BPO (Business Process Outsourcing), ASP (Application Service Provision) e KPO 
(Knowtedge Process Outsourcing). 
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Figura 7.4 - Visão dos processos do estágio de Desenho de Serviço 
Adaptado de The Cabinet Office (2007b) 


□ Coordenação do Desenho 58 : garante que os objetivos e as metas 
do estágio de Desenho de Serviço sejam atingidos, fornecendo e 
mantendo um ponto único de coordenação e controle de todos os 
demais processos deste estágio do ciclo de vida de serviço. Promove 
a utilização de métodos e políticas adequados e acordados, o plane¬ 
jamento e a utilização de recursos (capacidades), a gestão de riscos 
e ocorrências e a coordenação de todas as atividades de desenho 
dos serviços. 

□ Gerenciamento do Catálogo de Serviços : garante uma fonte única 
de informações consistentes e atualizadas sobre todos os serviços que 
estão operacionais e sobre aqueles que estão sendo preparados para 
entrar em operação. O Catálogo de Serviços tem duas subdivisões: 


58 Este processo foi incorporado à ITIL em sua versão 2011. 
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A Catálogo de Serviços de Negócio : contém a visão do cliente sobre 
os serviços de TI e os seus relacionamentos com os processos e as 
estruturas organizacionais do negócio. 

A Catálogo de Serviços Técnicos : contém detalhes técnicos de todos 
os serviços entregues ao cliente e os seus relacionamentos com os 
serviços de suporte, itens de configuração, componentes e servi¬ 
ços compartilhados necessários à entrega do serviço ao cliente. 

□ Gerenciamento do Nível de Serviço : visa manter e melhorar a qualidade 
dos serviços de TI através de um ciclo contínuo de atividades envolven¬ 
do planejamento, coordenação, elaboração, estabelecimento de acordo 
de metas de desempenho e responsabilidades mútuas, monitoramento e 
divulgação de níveis de serviço (em relação aos clientes), de níveis opera¬ 
cionais (em relação a fornecedores internos) e de contratos de apoio com 
fornecedores de serviços externos 59 . Este processo também é responsável 
pela elaboração e manutenção de um Plano de Melhoria dos Serviços 60 , 
um programa com ações priorizadas de melhoria para os serviços. 

□ Gerenciamento da Capacidade : assegura que a capacidade da infra- 
estrutura de TI absorva as demandas evolutivas do negócio de forma 
eficaz e dentro do custo previsto, balanceando a oferta de serviços em 
relação à demanda e otimizando a infraestrutura necessária à presta¬ 
ção dos serviços de TI. 

□ Gerenciamento da Disponibilidade : visa assegurar que os serviços de TI 
sejam projetados para atender e preservar os níveis de disponibilidade e 
confiabilidade requeridos pelo negócio, minimizando os riscos de inter¬ 
rupção através de atividades de monitoramento físico, solução de inci¬ 
dentes e melhoria contínua da infraestrutura e da organização de suporte. 

□ Gerenciamento da Continuidade dos Serviços de TI : desdobramento 
do processo de gerenciamento da continuidade do negócio, que visa 
assegurar que todos os recursos técnicos e serviços de TI necessários 
(incluindo sistemas, redes, aplicações, Central de Serviços, suporte 
técnico, telecomunicações etc.) possam ser recuperados dentro de um 
tempo preestabelecido. 


59 Em inglês, SLA (Service Levei Agreement), OLA (Operational Levei Agreement) e UC (Underpinning 
Contrací). 

60 Em inglês, SIP (Service Improvement Plan). 
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□ Gerenciamento da Segurança da Informação : abrange processos rela¬ 
cionados à garantia da confidencialidade, integridade e disponibilida¬ 
de de dados, assim como à segurança dos componentes de hardware 
e software, da documentação e dos procedimentos. Dessa forma, este 
processo alinha a segurança da TI com a segurança do negócio, e 
assegura que a segurança da informação seja gerenciada efetivamente 
durante todo o ciclo de vida dos serviços 61 . 

□ Gerenciamento de Fornecedores : gerencia fornecedores e os contra¬ 
tos necessários para suportar os serviços por eles prestados, visando 
prover um serviço de TI com qualidade transparente para o negócio, 
assegurando o valor do investimento feito. 


7.1.3.3.3 A implementação do Desenho de Serviço e suas implicações 
organizacionais e tecnológicas 

Para implementar os processos de Desenho de Serviço, uma organização 
deve analisar o impacto no negócio, definir os requisitos de nível de serviço, 
avaliar os riscos, executar as atividades de implementação (propriamente di¬ 
tas) e medir o processo. 

O Desenho de Serviço traz a necessidade da definição de uma matriz de 
responsabilidades na qual as atribuições de cada função devem estar bastante 
claras. Dentro do contexto do Gerenciamento de Serviços de TI, despontam 
funções como Gestor do Catálogo de Serviços, Gestor do Nível de Serviço, 
Gestor de Disponibilidade e assim por diante. 

Face às necessidades de desenho de arquiteturas tecnológicas para o servi¬ 
ço, o estágio de Desenho de Serviço poderá envolver atividades relacionadas 
a disciplinas tais como: 

□ Engenharia de Requisitos : compreende o entendimento e a docu¬ 
mentação dos requisitos dos usuários e dos negócios, além da garantia 
de rastreabilidade das mudanças em cada requisito 62 . 

□ Gerenciamento de Dados e Informações : aborda as formas de plane¬ 
jamento, coleta, geração, organização, utilização, controle, divulga¬ 
ção e descarte de dados e informações por parte de uma organização. 


61 Este processo está totalmente alinhado com os preceitos da ISO 27001. 

62 Este é um ponto de convergência com modelos familiares à Engenharia de Software, tais como 
CMMI, BABOKetc. 
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□ Gerenciamento de Aplicações : envolve o ciclo de vida dos itens de 
software responsáveis por funcionalidades específicas que suportam 
diretamente a execução de serviços de TI e de processos de negócio. 

Adicionalmente, há a necessidade de aquisição ou desenvolvimento de fer¬ 
ramentas para automatizar atividades de desenho do serviço (processos, infra- 
estrutura, software etc.) e para aumentar a eficácia, a eficiência, a segurança e a 
qualidade do gerenciamento do serviço durante a sua operaçáo contínua. Obvia¬ 
mente, náo basta somente ter as ferramentas, pois a dependência de processos e, 
principalmente, das pessoas é um fator crítico para o sucesso da sua implantação. 


7.1.3.4 Transição de Serviço 

O estágio de Transição de Serviço tem como principal objetivo colocar no 
ambiente de produção, em plena operação, um serviço que acabou de sair 
do estágio de Desenho de Serviço, garantindo o cumprimento dos requisitos 
preestabelecidos de custo, qualidade e prazo e que haja impacto mínimo nas 
operações atuais da organização. 

Um processo de transição de serviços, quando efetivo, agrega valor signifi¬ 
cativo a uma organização provedora de serviços, uma vez que assegura que os 
novos serviços possam ser utilizados de forma a maximizar o valor das opera¬ 
ções do negócio, e, principalmente, demonstra a capacidade da organização 
de gerenciar mudanças em seus serviços de forma consistente. 

Entre as características importantes deste estágio do ciclo de vida de servi¬ 
ço, podem ser relacionadas: 

□ Definição de um Sistema de Gerenciamento da Configuração , no qual 
existe uma Base de Dados de Gerenciamento da Configuração integrada 
(que pode ser produto da união de várias bases e bibliotecas de mídias 
locais), camadas de integração de informação e de processamento de co¬ 
nhecimento (em um nível intermediário) e uma camada de apresentação. 

□ Processos focados na gestão da mudança organizacional, no planeja¬ 
mento e no suporte à transição, na validação, no teste e na avaliação 
dos serviços a serem liberados para produção e no gerenciamento do 
conhecimento acerca de todos os aspectos envolvidos na transição. 
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□ Definição de um Sistema de Gestão do Conhecimento sobre Servi¬ 
ços , como uma ferramenta poderosa para a tomada de decisões mais 
rápidas e precisas acerca dos serviços. 


7.1.3.4.1 Princípios da Transição de Serviço 

A ITIL estabelece políticas explícitas formais focadas em aspectos impor¬ 
tantes para o processo de transição, tais como: 

□ Implementação de todas as mudanças no Portfólio ou Catálogo de 
Serviços através do processo de transição. 

□ Adoção de um jramework comum e de padrões conhecidos para me¬ 
lhorar a integração das partes envolvidas na transição. 

□ Maximização da reutilização de processos e sistemas já existentes. 

□ Integração dos planos de transição às necessidades do negócio, visan¬ 
do maximizar o valor das mudanças. 

□ Gerenciamento dos relacionamentos com todas as partes interessadas 
(. stakeholders ) nos serviços. 

□ Desenvolvimento de sistemas e processos para facilitar a transferência 
de conhecimento e o suporte às decisões. 

□ Planejamento dos pacotes de liberação e distribuição. 

□ Antecipação e gerenciamento das correções de desvios identificados 
na transição. 

□ Gerenciamento proativo de recursos através de várias instâncias do 
processo de transição de serviços. 

□ Detecção antecipada de falhas (no início do ciclo de vida do serviço), 
visando reduzir custos de correção. 

□ Garantia da qualidade do processo de transição e do serviço novo ou 
alterado já em operação. 


7.1.3.4.2 Os processos da Transição de Serviço 

Pode-se dizer que o estágio de Transição de Serviço tem similaridade com o 
ciclo de vida de um projeto, com produtos bem definidos e data prevista para 
acabar. Um dos processos importantes deste estágio é o de Planejamento e 
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Suporte à Transição, que visa planejar e coordenar os recursos necessários para 
colocar um serviço novo ou modificado no ambiente de produção, dentro do 
custo, do prazo e da qualidade estimados. 

Para tal, deve-se, entre outras atividades, avaliar constantemente a aderên¬ 
cia dos planos de transição à estratégia, integrar os planos junto ao cliente e 
aos demais fornecedores, gerenciar progresso, mudanças, problemas, riscos 
e desvios, além de prover todos os envolvidos do suporte necessário para o 
cumprimento dos objetivos e trabalhar na monitoração e melhoria contínua 
do desempenho do processo de transição. 

Além do processo de planejamento e suporte, o estágio de Transição de 
Serviço é suportado por mais seis processos de Gerenciamento de Serviços, 
descritos a seguir nesta seção. A relação entre esses processos no âmbito da 
Transição de Serviço pode ser visualizada na Figura 7.5. 
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Figura 7.5 - 0 Escopo da Transição de Serviço 
Adaptado de The Cabinet Office (2007c) 


□ Gerenciamento de Mudanças : visa assegurar o tratamento sistemáti¬ 
co e padronizado de todas as mudanças ocorridas no ambiente ope¬ 
racional, minimizando assim os impactos decorrentes de incidentes/ 
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problemas relacionados a essas mudanças na qualidade do serviço e 
melhorando, consequentemente, a rotina operacional da organização. 

□ Gerenciamento de Ativos de Serviço e da Configuração : abrange 
identificação, registro, controle e verificação de ativos de serviço e 
itens de configuração (componentes de TI como hardware, software 
e documentação relacionada), incluindo suas versões, componentes 
e interfaces, dentro de um repositório centralizado. Fazem parte tam¬ 
bém do escopo deste processo a proteção da integridade dos ativos 
e itens de configuração ao longo do ciclo de vida do serviço contra 
mudanças não autorizadas e o estabelecimento e a manutenção de 
um Sistema de Gerenciamento da Configuração completo e preciso. 

□ Gerenciamento da Liberação e da Distribuição : abrange o gerencia¬ 
mento do tratamento de um conjunto de mudanças em um serviço 
de TI, devidamente autorizadas (incluindo atividades de planejamen¬ 
to, desenho, construção, configuração e teste de itens de software 
e hardware), visando criar um conjunto de componentes finais e 
implantá-los em bloco em um ambiente de produção, de forma a 
adicionar valor ao cliente, em conformidade com os requisitos esta¬ 
belecidos na estratégia e no desenho de serviço. 

□ Validação e Teste do Serviço : relacionado à garantia da qualidade de 
uma liberação, incluindo todos os seus componentes de serviço, os 
serviços resultantes e a capacitação do serviço por ela viabilizada. Um 
serviço validado e testado está pronto para o uso dentro dos propósi¬ 
tos para os quais foi desenhado e construído. 

□ Avaliação de Mudança : visa criar meios padronizados e consistentes 
para avaliar o desempenho de uma mudança no contexto de uma 
infraestrutura de TI e serviços já existente, confrontando-o com as 
metas previstas, registrando e gerenciando os desvios encontrados. 

□ Gerenciamento do Conhecimento : visa garantir que a informação 
correta seja entregue no local apropriado, para uma pessoa que tenha 
competência para atuar no tempo certo, habilitando a tomada de 
decisões informadas. Para tal, a ITIL possui o conceito de Sistema de 
Gerenciamento do Conhecimento sobre Serviços, que pode ser visto 
como uma base de conhecimento mais ampla, contendo informações 
tais como a experiência da equipe, requisitos, habilidades e expectati¬ 
vas dos fornecedores e parceiros, histórico de configurações, etc. 
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Sáo também atividades comuns ao estágio de Transição de Serviço aquelas re¬ 
lacionadas ao gerenciamento da comunicação e de compromissos assumidos e ao 
gerenciamento da mudança organizacional, no âmbito de todos os stakeholders. 


7.1.3.4.3 A implementação da Transição de Serviço e suas implicações 
organizacionais e tecnológicas 

A implementação dos processos de Transição de Serviço em uma organiza¬ 
ção deve começar pela justificativa da sua importância estratégica para o negó¬ 
cio (uma vez que eles não são visíveis para o cliente), passando pelo desenho 
de seus padrões, políticas e relacionamentos e chegando à institucionalização 
do processo, levando em consideração aspectos de mudança cultural, do en¬ 
tendimento dos riscos e da medição de valor adicionado à organização. 

A Transição de Serviço acrescenta na matriz de responsabilidades mais al¬ 
gumas funções, dentro do contexto do Gerenciamento de Serviços de TI, tais 
como Gestor da Configuração, Gestor de Mudanças, Gestor de Ativos de 
Serviço, Gerente de Teste de Serviço e assim por diante. 

Tecnologicamente, há uma gama de ferramentas que poderão apoiar a 
Transição de Serviço, tais como: 

□ Sistema de Gerenciamento da Configuração (incluindo a integração 
das bases de dados de gerenciamento da configuração). 

□ Ferramentas de colaboração e ivorkfloiv. 

□ Automação de testes, gerenciamento de massas de teste. 

□ Automação de distribuição de liberações de software e da logística de 
hardware. 

□ Ferramentas de gestão do conhecimento, tais como dashboards , ge¬ 
renciamento eletrônico de documentos, gestão de conteúdo, etc. 

7.1.3.5 Operação de Serviço 

O estágio de Operação de Serviço é bastante crítico dentro do ciclo de vida 
do serviço, pois erros na condução, no controle e na gestão das atividades do 
dia a dia operacional poderão comprometer totalmente a disponibilidade do 
serviço, mesmo que ele tenha sido muito bem desenhado e que sua imple¬ 
mentação em produção tenha sido um sucesso. 
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A Operação de Serviço inclui em seu escopo todas as atividades recorrentes 
necessárias para entregar e suportar os serviços. Seu objetivo é coordenar e exe¬ 
cutar tais atividades dentro dos níveis de serviço estabelecidos com os clientes. 

Esta publicação da ITIL possivelmente é a mais familiar para os conhe¬ 
cedores da antiga versão 2, pois abriga os processos mais conhecidos de “Su¬ 
porte a Serviços” (gerenciamento de incidentes e problemas) e a função de 
Central de Serviços. Entretanto, uma importante mudança foi a separação 
dos conceitos de incidente, evento e requisição de serviços, o que melhorou 
significativamente o entendimento. 


7.1.3.5.1 Princípios da Operação de Serviço 

Um dos maiores desafios deste estágio de Operação de Serviço é seguir pro¬ 
cessos, funções e atividades que visam a regularidade da entrega dos serviços 
nos níveis preestabelecidos, dentro de um ambiente sujeito a mudanças fre¬ 
quentes e, muitas vezes, imprevisíveis. Um dos papéis da Operação do Serviço 
é encontrar um ponto de equilíbrio entre conjuntos de prioridades totalmen¬ 
te conflitantes, para minimizar riscos. A Tabela 7.2 ilustra estes conflitos e os 
riscos de pender para um dos lados. 


Tema 

Posições Conflitantes 

Riscos nos Extremos 

Visualização 

Visão externa do negócio (conjunto de 
serviços de TI) 

Altos níveis de desempenho sem saber como 
foram atingidos. 

Visão interna de TI (conjunto de 
componentes de tecnologia) 

Não atender aos requisitos do cliente. 

Comportamento 

Estabilidade 

Ignorar requisitos de mudança no negócio. 

Responsividade 

Gastar demais em mudanças. 

Foco 

Foco em Custo 

Perder qualidade do serviço devido aos cortes 
pesados de custos. 

Foco em Qualidade 

Gastar muito para entregar níveis de serviços 
maiores do que os estritamente necessários. 

Atuação 

Reatividade 

Não suportar a estratégia do negócio. 

Proatividade 

Tendência a ajustar serviços que não estão com 
problemas, aumentando a taxa de mudanças. 


Tabela 7.2 - Conflitos a serem resolvidos pela Operação do Serviço (e riscos associados aos extremos) 

Adaptado de The Cabinet Office (2011 d) 
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As equipes de Operação de Serviço devem sempre estar conscientes de que 
são provedoras de serviços para o negócio e que uma das habilidades mais 
importantes a serem exercidas é a comunicação . O quanto antes a Operação 
de Serviço se envolver nas atividades de desenho e transição, menores serão os 
riscos de problemas inesperados durante a fase recorrente. 


7.1.3.5.2 Os processos da Operação de Serviço 

O estágio de Operação de Serviço é suportado por um conjunto de cinco 
processos de Gerenciamento de Serviços, descritos a seguir nesta seção. A Fi¬ 
gura 7.6 mostra como esses processos se relacionam nesse contexto. 



Figura 7.6 - Processos da Operação de Serviço 
Adaptado de The Cabinet Office (2011 d) 


□ Gerenciamento de Eventos : monitora todos os eventos que ocorrem 
na infraestrutura de TI, para atestar a normalidade da operação. Caso 
sejam detectadas condições de exceção, este processo deve escalar 
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para resolução técnica ou para atuação hierárquica. Eventos podem 
ser exceções (incidentes, problemas, mudanças), advertências ou pe¬ 
didos de informação que terão tratamentos distintos. 

□ Gerenciamento de Incidentes : visa restaurar a operação normal de 
um serviço no menor tempo possível, de forma a minimizar os im¬ 
pactos adversos para o negócio, garantindo que os níveis de qualidade 
e disponibilidade sejam mantidos dentro dos padrões acordados (tra¬ 
ta o efeito e não a causa). 

□ Gerenciamento de Problemas : visa minimizar os impactos adversos 
de incidentes e problemas para o negócio, quando causados por fa¬ 
lhas na infraestrutura de TI, assim como prevenir que incidentes re¬ 
lacionados a essas falhas ocorram novamente. Pode ter uma atuação 
reativa (resolução de problemas em resposta a um ou mais incidentes) 
ou proativa (identificando e resolvendo problemas e falhas conheci¬ 
das antes da ocorrência dos incidentes). 

□ Cumprimento de Requisições : trata requisições dos usuários que não 
foram geradas por um incidente, mas que foram originadas a partir de 
uma solicitação de serviço 63 ou de uma simples solicitação de informação. 

□ Gerenciamento de Acesso : controla o acesso de usuários ao direito 
de utilizar os serviços, garantindo-o àqueles que foram previamente 
autorizados e restringindo-o a todos os demais. Consiste na execução 
das políticas e ações definidas anteriormente nos processos de Ge¬ 
renciamento da Disponibilidade e Gerenciamento da Segurança da 
Informação (Desenho de Serviço). 

São executadas também, no escopo da Operação de Serviço, atividades ope¬ 
racionais de todos os demais processos de Gerenciamento de Serviços de TI. 


7.1.3.5.3 As funções da Operação de Serviço 

Função é definida pela ITIL como “um conceito lógico referente a pessoas e 
medidas automatizadas que executam um determinado processo, atividade, ou 
uma comunicação entre eles”. A Operação de Serviço possui quatro funções: 


63 Na versão 2 da ITIL, as Service Requests eram tratadas da mesma forma que os incidentes, o que 
foi resolvido na ITIL V3. 
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□ Central de Serviços (Service Desk) : função destinada a responder rapi¬ 
damente a questões, reclamações e problemas dos usuários, de forma 
a permitir que os serviços sejam executados com o grau de qualidade 
esperado. Pode ser implementada de forma centralizada, local ou vir¬ 
tual, nas modalidades de: 

A Central de Atendimento ( Call Center ) : ênfase no atendimento de 
um grande número de chamadas telefônicas. 

A Help Desk : visa gerenciar, coordenar e resolver incidentes no me¬ 
nor tempo possível, assegurando que nenhuma chamada seja per¬ 
dida, esquecida ou ignorada. 

A Central de Serviços ( Service Desk) : abordagem global, que per¬ 
mite a integração dos processos de negócio à infraestrutura de 
gerenciamento dos serviços de TI. 

□ Gerenciamento Técnico {TechnicalManagement) -, função relacionada 
a grupos, áreas ou equipes que possuem experiência e conhecimento 
técnico especializado para suportar a operação. Deve também garan¬ 
tir que haja recursos treinados para desenhar, construir, fazer as tran¬ 
sições, operar e melhorar a tecnologia utilizada nos serviços. 

□ Gerenciamento das Operações de TI ( IT Operations Management) : 

função relacionada a grupos, áreas ou equipes responsáveis pela exe¬ 
cução das atividades diárias da operação (tais como gerenciar a cadeia 
de parceiros em uma área de Procurement ou receber materiais envia¬ 
dos por clientes em uma área de Logística). Esta função se subdivide 
em Controle de Operações e Gerenciamento de Facilidades. 

□ Gerenciamento de Aplicações ( Application Management) -, função 
responsável por gerenciar aplicações ao longo de seu ciclo de vida, 
que desempenha um importante papel no desenho, no teste e nas 
melhorias das aplicações que suportam serviços de TI. Aborda o 
ciclo de vida completo das aplicações de software relacionadas à 
implementação de serviços de TI, incluindo atividades de desen¬ 
volvimento (levantamento de requisitos, planejamento, desenho, 
construção e teste) e de gerenciamento (implantação, operação, su¬ 
porte e otimização) 64 . 


64 Adescrição desta função substituiu a publicação “Gerenciamento de Aplicações” da versão 2 da ITIL. 
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7.1.3.5.4 Atividades comuns da Operação de Serviço 

Além de processos e funções, há um conjunto de atividades técnicas alta¬ 
mente especializadas cujo objetivo é garantir que a tecnologia requerida para a 
entrega e o suporte aos serviços esteja funcionando em perfeito estado. Entre 
essas atividades, figuram: 

□ Monitoração e controle. 

□ Operações de TI (gerenciamento de console, programação de jobs , 
backup e recuperação, impressão). 

□ Gerenciamento do mainframe. 

□ Gerenciamento e suporte a servidores. 

□ Gerenciamento de redes. 

□ Armazenamento de dados. 

□ Administração de banco de dados. 

□ Gerenciamento de serviços de diretório. 

□ Suporte a desktops. 

□ Gerenciamento de middleware. 

□ Gerenciamento da Internet/Web. 

□ Gerenciamento de facilidades e data centers etc. 

7.1.3.5.5 A implementação da Operação de Serviço e suas implicações 
tecnológicas 

A implementação dos processos de Operação de Serviço em uma organi¬ 
zação pode começar pelo gerenciamento das mudanças no ambiente atual 
da operação e pela utilização de processos de gerenciamento de projetos nas 
ações de melhoria que representarem mudanças significativas na infraestru- 
tura ou nos processos. Avaliar e gerenciar os riscos da operação e a alocação 
antecipada dos colaboradores nos estágios de desenho e transição também são 
boas práticas a serem consideradas. 

Tecnologicamente, há uma gama de ferramentas que poderão apoiar a 
Operação de Serviço, tais como: 

□ Ferramentas de autoajuda para o usuário (para minimizar a quanti¬ 
dade de eventos). 
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□ Sistema de Gerenciamento da Configuração integrado, que deve per¬ 
mitir que todos os itens de configuração fiquem armazenados junta¬ 
mente com seus atributos relevantes em uma localidade centralizada. 

□ Controle remoto de estações. 

□ Ferramentas de diagnóstico. 

□ Elaboração de relatórios e dasbboards de indicadores. 

7.1.3.6 Melhoria Contínua de Serviço 

Os serviços de TI devem continuamente ser alinhados e, principalmente, 
integrados às necessidades do negócio (que são dinâmicas por natureza), atra¬ 
vés da identificação e da implementação de ações de melhoria para o suporte 
aos processos de negócio. 

Este é o propósito principal do estágio de Melhoria Contínua de Servi¬ 
ço. Seu escopo contém atividades que suportam o planejamento contínuo 
da melhoria de processos, tais como análise das informações gerenciais e 
das tendências quanto ao atingimento dos níveis de serviço e dos resulta¬ 
dos desejados pelos serviços, avaliações de maturidade e auditorias inter¬ 
nas periódicas, pesquisas de satisfação junto aos clientes, gerenciamento 
do Plano de Melhoria de Serviços (criado pelo processo de Gerenciamento 
do Nível de Serviço) e identificação de oportunidades de melhoria. Os 
conceitos aqui presentes são suportados também pelos frameworks , mo¬ 
delos, padrões e sistemas de qualidade mais utilizados no mercado, tais 
como CobiT, CMMI, PMBOK etc. 

Os benefícios de uma implementação bem-sucedida da Melhoria Con¬ 
tínua de Serviço podem ser mensurados através de métricas focadas, por 
exemplo, na quantidade de falhas, na realização de melhorias e em concei¬ 
tos como retorno sobre o investimento (ROI) e valor sobre o investimento 
(VOI). 

As oportunidades de melhoria dos serviços podem ser encontradas em vá¬ 
rios pontos do ciclo de vida de serviço. A Figura 7.7 mostra a interação da 
Melhoria Contínua de Serviço com os demais estágios. 
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Figura 7.7 - Melhoria Contínua de Serviço e o Ciclo de Vida de Serviço 
Adaptado de The Cabinet Office (2011 e) 


7.1.3.6.1 Princípios da Melhoria Contínua de Serviço 

Um programa de melhoria sempre deve estar vinculado às oportunidades 
de mudança organizacional e por isso deve ser conduzido por uma equipe que 
possua representatividade e autoridade para promovê-las e onde haja papéis 
e responsabilidades bem definidas. Nesse estágio, é importante também estar 
atento às influências externas (regulações, concorrência, requisitos de clientes 
etc.) e internas (estruturas organizacionais, cultura, capacidade) que podem 
ser fontes para oportunidades de melhoria 65 . 

Outras fontes de valores de referência podem ser obtidas através de bench¬ 
markings ou da análise de dados históricos. Os processos de Gerenciamento do 
Nível de Serviço, Gerenciamento de Problemas e de Gerenciamento do Conhe¬ 
cimento podem ser considerados chaves para este processo, pois fornecem uma 
base importante de conhecimento medido e estruturado acerca dos serviços, sobre 
a qual as ações de melhoria podem ser planejadas e conduzidas adequadamente. 


65 Um dos métodos que pode ser útil para identificar tais fontes é a análise SWOT, que ressalta os 
pontos fortes, os pontos fracos, as oportunidades e as ameaças para o negócio. 
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Há dois tópicos 66 cuja importância é fundamental para a implementação e 
a operação da Melhoria Contínua de Serviço: 

□ Medição do Serviço : visa prover informações sobre o serviço dentro de 
uma visão completa orientada à integração com o negócio. Para tal, reco- 
menda-se a criação de um modelo de medição de serviço que estabeleça 
diferentes níveis para a medição e para a visualização através de relatórios: 
A Componente : medições acerca de aspectos físicos e técnicos, como 

disponibilidade, desempenho, capacidade, falhas, mudanças etc. 

A Serviço : medições sobre aspectos funcionais e de relacionamento 
direto com o cliente (pesquisas de satisfação, reclamações, quali¬ 
dade do serviço). 

A Processos que suportam os serviços: medições de progresso, con¬ 
formidade, eficácia, eficiência. 

A Scorecards de Serviços : visões estáticas periódicas de um serviço 
em particular. 

A Dashboard de Serviços : contém as mesmas medidas dos scorecards 
de serviços, mas disponibilizadas em tempo real para a TI e para 
os negócios. 

A Scorecard de TI ou Balanced Scorecard : visões de alto nível com 
consolidações das medições, visando refletir as metas e os objeti¬ 
vos táticos e estratégicos. 

□ Relato do Serviço : envolve a composição de relatórios de serviço a 
partir dos dados coletados e monitorados durante a entrega do servi¬ 
ço, além da identificação do seu objetivo, do público-alvo e da utili¬ 
zação planejada para as informações contidas nestes relatórios. 

Recomenda-se que os resultados das medições e das melhorias efetuadas 
sempre estejam associados a benefícios para a organização, que poderão ser 
avaliados de forma quantitativa como retorno ou valor sobre o investimento. 
Assim, torna-se mais fácil a comunicação, e mesmo a justificativa, para manu¬ 
tenção e crescimento do programa de melhoria contínua. 

Vários métodos e técnicas podem ser utilizados nesse estágio, como forma 
de garantir consistência, tanto na execução das medições e ações de melhoria 


66 Na ITIL V3 (2007), esses dois tópicos eram tratados como processos do estágio de Melhoria Contínua de 
Serviço, o que gerou confusão na comunidade (uma vez que os elementos de medição e relato devem estar 
presentes na descrição de qualquer processo). Este ajuste conceituai foi efetuado na versão 2011 da ITIL. 
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quanto nos relatos de informações. Entre eles, podem ser relacionadas ava¬ 
liações formais, benchmarkings , Balanced Scorecard, análise SWOT, além das 
práticas dos demais processos de Gerenciamento de Serviços de TL 


7.1.3.6.2 Processos da Melhoria Contínua de Serviço 

Um dos princípios mais importantes deste estágio é a mediçáo do serviço. Ba¬ 
sicamente, medições são realizadas para validar decisões tomadas, direcionar ati¬ 
vidades para o atingimento de metas, justificar direcionamentos necessários e/ou 
identificar pontos onde é necessário intervir com mudanças ou ações corretivas. 
Por isso, náo basta medir simplesmente, mas é importante saber por que medir, 
quando parar de medir e também se os resultados dessas medições estáo sendo 
úteis para alguma área da organização. Da mesma forma, simplesmente melhorar 
algo náo é suficiente, pois deve-se estabelecer a visáo de futuro, fixar referências 
iniciais e metas a serem atingidas e avaliar posteriormente se houve sucesso ou 
náo. Esses conceitos fazem parte do Processo de Melhoria em 7 Passos, o único 
processo desta fase do ciclo de vida de serviço, que está ilustrado na Figura 7.8: 
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Figura 7.8 - Processo de Melhoria em 7 Passos 
Adaptado de The Cabinet Office (2011 e) 
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A versão 2011 da ITIL reforça a necessidade de identificar e categorizar 
todas as iniciativas ou possibilidade de melhoria como Registros de Melhoria 
Contínua de Serviço, e que para cada uma delas sejam estabelecidos um prazo 
de resolução e os benefícios que a operação de serviços poderá obter com a 
sua implementação, de forma que possa haver uma lista de priorização para 
tais registros. 


7.1.3.6.3 A implementação da Melhoria Contínua de Serviço e suas 
implicações organizacionais e tecnológicas 

Os processos de Melhoria Contínua de Serviço em uma organização po¬ 
dem ser implementados a partir de vários caminhos. Um deles é a abordagem 
por serviço , no qual um ponto de melhoria de um determinado serviço é 
escolhido como piloto; a abordagem do ciclo de vida focaliza as interfaces 
deste estágio com os demais estágios; na abordagem por grupo funcional, o 
piloto pode ser feito sobre uma equipe responsável por ativos com alto grau 
de falhas. Em qualquer abordagem, é muito importante considerar o grau de 
maturidade dos processos de gerenciamento de serviços de TI da organização. 
Quanto menos maduros esses processos, mais difícil é a aplicação do Processo 
de Melhoria em 7 Passos. 

Conforme dito anteriormente, melhorias implicam em mudanças organi¬ 
zacionais. Na maioria dos casos, a introdução da ITIL certamente começará 
por ações de melhoria em operações ou serviços que já estão em produção. 
Assim, deve-se pensar em criar mecanismos de gestão de mudanças organiza¬ 
cionais (desde a sua identificação até a institucionalização), além de estratégias 
e planos de comunicação por toda a organização. 

A matriz de responsabilidades da organização requer, para os processos 
de Melhoria Contínua de Serviço, habilidades específicas para obtenção de 
dados (precisão, acurácia, experiência técnica), processamento dos dados (mé¬ 
todo, habilidades numéricas, programação), análise dos dados (perfil analíti¬ 
co, modelagem, inovação) e apresentação/utilização da informação (geren¬ 
ciamento, comunicação, tratamento de situações complexas e incertas etc.). 
Além dessas, é reforçada a necessidade de um Gerente de Melhoria Contínua 
de Serviços e de um Gerente de Nível de Serviço (neste último caso, devido às 
implicações deste processo no programa de melhoria contínua). 







258 Implantando a Governança de TI - 4 a edição 


Tecnologicamente, há uma gama de ferramentas que poderão apoiar a Me¬ 
lhoria Contínua de Serviço (além daquelas já mencionadas nos demais está¬ 
gios), tais como: 

□ Ferramentas para análise estatística. 

□ Ferramentas de business intelligence e geraçáo de relatórios. 


7.1.4 Aplicabilidade do modelo 

As práticas da ITIL sáo compatíveis com várias modalidades de prestação 
de serviços de TI, tanto locais quanto remotas, que necessitem de uma forte 
abordagem de gestão. Pela ênfase dada aos aspectos tecnológicos e à sua abor¬ 
dagem de integração aos requisitos do negócio, o modelo tem sido bastante 
utilizado em projetos e operações contínuas envolvendo itens de infraestru- 
tura, tais como manutenção de equipamentos, gerenciamento de redes, su¬ 
porte à utilização de aplicações e outsourcing de processos de impressão, entre 
outros. 

Quando associado às práticas de modelos específicos orientados a software 
(como o CMMI, por exemplo), a ITIL pode ser aplicada a serviços específicos 
de gerenciamento de serviços relacionados a aplicações, tais como manuten¬ 
ções, operações de fábrica de software, outsourcing de desenvolvimento etc. 
Através da função de Gerenciamento de Aplicações, tais modelos também po¬ 
dem ser utilizados de forma complementar à ITIL, no âmbito das aplicações 
que suportam os serviços de TL 

O advento da ITIL V3 (e, posteriormente, da ITIL 2011) trouxe ao mo¬ 
delo uma gama de possibilidades de aplicação nas organizações, das grandes 
corporações até as empresas de pequeno porte, das empresas com alto grau 
de maturidade em seus processos até aquelas que ainda estão iniciando seus 
passos na busca da qualidade de serviços. 

O ciclo de vida de serviço pode ser utilizado a partir de seu primeiro 
estágio, a Estratégia do Serviço. Esta abordagem é bastante indicada para 
situações nas quais uma organização esteja concebendo novos serviços 
para oferecer ao seu mercado, ou esteja repensando os seus investimentos 
com foco no seu Portfólio de Serviços e nos Catálogos de Serviços atuais 
e futuros. 
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Entretanto, a grande maioria das organizações já possui serviços consoli¬ 
dados, em operação por muito tempo. Para estas, o sucesso das suas iniciati¬ 
vas de TI depende muito de uma gestão efetiva do seu Portfólio de TI, que 
coordene os investimentos e os esforços entre seus projetos, ativos, processos 
e serviços de TI. Para esses casos, parece lógico iniciar o ciclo de vida pelas 
atividades da Melhoria Contínua de Serviço. 

Dessa forma, a utilização das informações oriundas da análise da base de 
conhecimento da organização (níveis de serviço, histórico de problemas e 
reclamações, ações corretivas e preventivas passadas ou em curso, pesquisas 
de satisfação, demandas dos clientes e das áreas internas, análises de gaps, 
avaliações internas de desempenho, benchmarkings etc.), analisadas sob a 
égide da estratégia de negócios e de TI, certamente resultará em um pla¬ 
no de melhoria dos serviços focado no valor que deve ser adicionado ao 
negócio. 

Deve ser dada atenção especial ao estágio de Transição do Serviço, que 
representa o umbral a ser cruzado por um serviço que foi concebido e de¬ 
senhado para atender aos requisitos do negócio e que está prestes a ser lan¬ 
çado à operação junto aos clientes e usuários. É nesta fase que este serviço 
deve passar por todos os testes necessários para atestar a sua capacidade de 
satisfazer os níveis exigidos pelo negócio, e que também deve ser preparado 
para distribuição pelos seus vários usuários. As abordagens de gerenciamen¬ 
to de projetos (PMI, PRINCE 2, etc.) certamente serão de muita valia neste 
momento. 

Em geral, qualquer que seja o ponto de entrada, recomenda-se que a im¬ 
plementação do modelo seja feita de forma gradual, partindo de um escopo 
reduzido de operações como piloto e promovendo roll-outs sucessivos para as 
demais operações, respeitando sempre as interdependências existentes entre 
os processos de gestão e os requisitos de disponibilidade e continuidade dos 
serviços. Devem ser consideradas também com muita atenção as questões re¬ 
lacionadas à estrutura organizacional e à tecnologia que suportam os serviços, 
de forma que os seus pontos fortes sejam aproveitados ao máximo, e que as 
eventuais mudanças possam ser efetuadas com impacto mínimo na disponi¬ 
bilidade e na continuidade do negócio. 

Assim como todos os modelos de melhores práticas, a ITIL também 
pode precisar de adaptações em função das características de cada organi- 
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zaçáo de TI, dos tipos de serviços previstos em seu catálogo e dos níveis de 
serviço exigidos. Da mesma forma, uma organização deve sempre conside¬ 
rar os desafios, os fatores críticos de sucesso e os riscos internos à sua estru¬ 
tura, assim como aqueles inerentes à adoção de um modelo de qualidade. 


7.1.5 Benefícios do modelo 

Várias organizações têm relatado benefícios com a adoção e implemen¬ 
tação da ITIL como modelo de melhores práticas em gerenciamento de TI, 
conforme mostram os exemplos a seguir 67 : 

□ Corte dos custos operacionais de 6% a 8%. 

□ Redução de 10% na quantidade de chamadas do help desk. 

□ Redução de 40% nos custos de suporte. 

□ Aumento da taxa de atingimento do tempo de resposta para inciden¬ 
tes em serviços relacionados à Internet, de 60% para 90%. 

□ Reduções superiores a 40% na indisponibilidade dos sistemas. 

□ Aumento significativo no ROI dos serviços de TI. 

□ Economia da ordem de grandeza de centenas de milhares de dólares. 

Medições feitas pelo Gartner Group mostram que a migração de uma si¬ 
tuação onde não há qualquer processo de Gerenciamento de Serviços de TI 
para a adoção completa das melhores práticas poderá reduzir o custo total de 
propriedade (TCO) de uma organização em cerca de 48% 68 . 

Além dos resultados quantitativos, a implementação do Gerenciamento 
de Serviços de TI através da ITIL poderá trazer resultados qualitativos tais 
como: 

□ Melhoria da satisfação dos clientes. 

□ Redução gradativa dos custos de treinamento, principalmente se o 
padrão ITIL se tornar corporativo. 

□ Melhoria da disponibilidade dos sistemas e aplicações. 

□ Melhoria da produtividade das equipes de serviços (já que todos os 
envolvidos conhecem seus papéis e responsabilidades). 


67 Fonte: Plnk Elephant, 2006. The Benefits of ITIL Whlte Paper. 

68 Fonte: Lewis & Schwartz (2009). 
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□ Redução dos custos relacionados aos incidentes e problemas, devido 
à detecção e eliminação antecipada. 

□ Redução dos custos indiretos que influenciam substancialmente o 
custo total de propriedade (manutenção, suporte etc.). 

□ Melhor utilização dos recursos de TI. 

□ Maior clareza no custeio dos serviços. 

□ Aplicação de uma visão organizacional ao trabalho dos indivíduos. 

□ Melhoria da satisfação interna dos colaboradores. 

□ Redução da rotatividade dos colaboradores. 

Outros benefícios poderão ser percebidos indiretamente, tais como a redu¬ 
ção do custo das oportunidades de negócio perdidas (as melhores práticas da 
ITIL têm sido utilizadas como embasamento técnico para análise e seleção de 
propostas de prestação de serviços), ou da falta de capacitação para o atendi¬ 
mento dos serviços. 

Com a visão através do ciclo de vida do serviço presente na ITIL 2011, 
alguns benefícios adicionais podem ser relacionados: 

□ Subsídios concretos para justificar investimentos em TI (através de 
fatos e dados extraídos da própria organização). 

□ Maior clareza na demonstração do retorno sobre os investimentos 
(ROI) e do valor dos investimentos (VOI) nos serviços de TI. 

□ Visão clara do Portfólio de Serviços, como ferramenta estratégica de 
priorização dos investimentos nos serviços de TI. 

□ Maior flexibilidade para adaptação às organizações de vários tipos e 
níveis de maturidade. 

□ Aumento da convergência com outros modelos de melhores práticas 
em uso no mercado. 

□ Direcionamento da TI para a integração (e não simplesmente o ali¬ 
nhamento) com o negócio, com base no valor que ela representa. 

□ Medições de desempenho dos serviços e de seus componentes, desdo¬ 
bradas com base no valor do negócio. 

□ Relação direta entre os ativos de serviços de TI e os serviços do 
negócio. 
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7.1.6 Certificações relacionadas 
7.1.6.1 Foco individual 

O esquema de qualificação da ITIL baseia-se em um sistema de créditos 
cumulativos, que permite três níveis de certificação: 

□ Nível Básico ( Foundation ) : mais generalista, destina-se a prover os 
profissionais de bons fundamentos acerca dos conceitos chaves, 
da terminologia e dos processos da ITIL (a partir da V3, vale 2 

créditos). 

□ Nível Intermediário : possui um grau maior de especialização e pode 
ser atingido através de uma das duas correntes de conhecimento, con¬ 
forme a preferência do postulante: 

A Corrente do Ciclo de Vida : possui um módulo para cada um dos 
cinco estágios do ciclo de vida (Estratégia de Serviço, Desenho de 
Serviço, Transição de Serviço, Operação de Serviço e Melhoria 
Contínua de Serviço), cada um deles valendo 3 créditos. 

A Corrente da Capacitação : possui quatro módulos, representando 
agrupamentos de capacitações (Portfólio de Serviços e Gerencia¬ 
mento do Relacionamento, Desenho e Otimização do Serviço, 
Monitoração e Controle do Serviço, Operação e Suporte ao Ser¬ 
viço), cada um deles valendo 4 créditos. 

□ Nível Avançado : possui o curso “Gerenciando através do Ciclo de 
Vida”, que aborda a visão completa sobre a abordagem de ciclo 
de vida no contexto do Gerenciamento de Serviços de TI e vale 5 

créditos. 

Ao acumular um mínimo de 22 créditos, o profissional poderá receber o 
título “ITIL Expert”. Após este título, ainda poderá galgar mais um degrau, 
o de “ITIL Master”. 

A Figura 7.9, a seguir, mostra o esquema completo de certificação da 
ITIL. 








Modelos para Gerenciamento de Serviços de TI 263 



Um profissional é considerado qualificado em um dos níveis de certificação 
da ITIL após um exame de qualificação profissional ministrado por um dos 
seguintes institutos oficiais (acompanhado por um comitê de representantes 
do Cabinet Office e do itSMF 69 ): 

□ APM Group (APMG), uma empresa global autorizada a fornecer ser¬ 
viços de validação e certificação. 

□ EXIN (.Examination Institute for Information Science in the Netherlands). 


7.1.6.2 Foco Organizacional 

Pelo seu alto grau de correlação, a ISO/IEC 20000 (apresentada a seguir 
neste livro) é um padrão internacional altamente recomendado para certificar 
organizações quanto à utilização de melhores práticas em Gerenciamento de 
Serviços de TI, como as descritas pela ITIL. 


69 IT Service Management Forum, organização sem fins lucrativos fundada no Reino Unido em 1991 e 
com representações em vários países (inclusive o Brasil), cuja missão é ajudar a desenvolver e promover 
as melhores práticas e os padrões no Gerenciamento de Serviços de TI. 
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7.2 ISO/IEC 20000 

7.2.1 Histórico do modelo 

Publicada inicialmente em 2000 pela BSI 70 , a norma BS 15000 ( Britisb 
Standards Institutions Standard for IT Service Management) foi o primei¬ 
ro padrão mundial especificamente direcionado para o Gerenciamento de 
Serviços de TI. Esta norma, que já estava alinhada com as diretrizes da 
ITIL, tinha foco acentuado nas disciplinas de suporte e entrega de servi¬ 
ços de TI. 

A partir de recomendações de seus primeiros usuários, a BS 15000 foi re¬ 
escrita e publicada novamente em 2002, estruturada em duas partes: Especifi¬ 
cação (contendo os requisitos básicos da norma) e Código de Prática (conten¬ 
do diretrizes de suporte detalhadas para a especificação). Como publicações 
complementares, havia um caderno de autoavaliação para as organizações, em 
relação à satisfação dos requisitos e um guia gerencial para o Gerenciamento 
de Serviços de TI. 

Entretanto, o fato de ser uma norma britânica dificultava bastante a sua 
difusão em âmbito mundial. Para ilustrar essa situação, até o final de 2005 
havia apenas cerca de cinquenta empresas certificadas na BS 15000 em todo 
o mundo (a maioria delas nos continentes europeu e asiático). A Internatio¬ 
nal Organization for Standardization (ISO), em conjunto com o International 
Eletrotechnical Comission (IEC), evoluiu a BS 15000 para o padrão interna¬ 
cional ISO/IEC 20000 em dezembro de 2005. 

A evolução dessa norma para um padrão internacional aumentou a sua 
relevância para organizações de TI situadas em outros mercados, tais como os 
Estados Unidos e a América Latina. Além disso, como padrão internacional, 
ela fornece um entendimento comum acerca do gerenciamento de serviços de 
TI em todo o mundo, uma vez que cobre os aspectos responsáveis por 80% 
dos gastos totais em TI da maioria das organizações. 

Em novembro de 2010, foi publicada a segunda edição da Parte 1 da 
norma, incluindo melhorias como refinamento de algumas definições, ali¬ 
nhamento mais próximo com a ISO 9001, a ISO/IEC 27001 e a ITIL 
V3, a introdução do conceito de Sistema de Gestão de Serviços (SGS) e a 


70 British Standards Institution. 
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junção de algumas cláusulas visando maior clareza e coesão conceituai (por 
exemplo, reunião de todos os requisitos do SGS em uma única cláusula e 
anexação do processo de Gerenciamento de Liberações aos processos de 
controle). 

As partes 1 e 2 da norma ISO/IEC 20000 foram adequadas pela ABNT 
(Associação Brasileira de Normas Técnicas) em 2008 para o mercado brasi¬ 
leiro. Atualmente existem edições em língua portuguesa que cobrem pratica¬ 
mente toda a norma. 


7.2.2 Objetivos do modelo 

Regulamentar um padrão para o Gerenciamento de Serviços de TI, através 
da uniformização dos conceitos e da visão dos processos que o implementam, 
permitindo assim que os provedores de serviços de TI compreendam os meios 
através dos quais poderão planejar, executar, verificar e melhorar continua¬ 
mente a qualidade dos serviços entregues, em conformidade com os requisitos 
estabelecidos junto ao negócio e a seus clientes. 

Esta norma pode ser utilizada em conjunto com outras normas, tais como 
a ISO 9001:2000 e a ISO/IEC 27001, com um foco específico no Gerencia¬ 
mento de Serviços de TI. 


7.2.3 Estrutura do modelo 

7.2.3.1 Divisão dos documentos 

A ISO/IEC 20000 está estruturada em cinco partes: 

□ Parte 1 - Requisitos do Sistema de Gestão de Serviços : consiste na 
especificação formal da norma e define os requisitos para o gerencia¬ 
mento de serviços, dentro de um nível aceitável de qualidade e em 
conformidade com os requisitos do negócio. Esta parte descreve o 
que deve ser levado em consideração na implementação do gerencia¬ 
mento de serviços de TI, visando a certificação dos processos relacio¬ 
nados em relação aos requisitos da norma. 
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□ Parte 2 - Código de Prática : guia prático que contém um conjunto 
de diretrizes baseadas na experiência do mercado, para orientar as 
empresas de serviços a planejar melhorias em seus serviços ou a se 
preparar para serem auditadas e certificadas na norma, em relação a 
cada um dos requisitos presentes na Parte 1. 

□ Parte 3 - Diretrizes de Escopo : contém orientações para definição do 
escopo e da aplicabilidade da norma aos diversos tipos de organiza¬ 
ções de serviços de TI. 

□ Parte 4 - Modelo de Referência de Processos : bastante útil para a 
definição dos processos de Gerenciamento de Serviços de TI, em 
alinhamento com a ISO/IEC 15504-2 - Auditoria de processos 
de TL 

□ Parte 5 - Exemplo de Plano de Implementação : apoio à preparação 
para a implementação de um Sistema de Gerenciamento de Servi¬ 
ços de TI. 

Neste livro, daremos foco apenas à primeira parte, que contém o núcleo e 
os requisitos da norma. 


7.2.3.2 O Sistema de Gestão de Serviços 

A ISO/IEC 20000 tem como espinha dorsal um Sistema de Gestão de Ser¬ 
viços (SGS), que dirige e controla as atividades de gerenciamento de serviços 
do provedor de serviços. O SGS inclui todas as políticas, os objetivos, os pla¬ 
nos, os processos, os documentos e os recursos de gerenciamento de serviços 
requeridos para o desenho, a transição, a entrega e a melhoria dos serviços e 
para atender aos requisitos preconizados pela norma. A Figura 7.10 mostra a 
visão do SGS na perspectiva da norma: 
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Figura 7.10 - Sistema de Gestão de Serviços, na visão da ISO/IEC 20000 
Adaptado de ABNT (2011) 


7.2.3.3 Conteúdo 

A Parte 1 da norma ISO/IEC 20000 está estruturada em nove seções: 

□ Escopo : nesta seção são enumerados os propósitos e cenários para os 
quais a norma é recomendada, e o Sistema de Gestão de Serviços é 
apresentado. 

□ Referências Normativas : nesta seção é referenciada a Parte 2 da nor¬ 
ma (Diretrizes para aplicação dos sistemas de gestão de serviços). 

□ Termos e Definições : é estabelecido um glossário contendo a ter¬ 
minologia e as definições aplicáveis aos propósitos da norma. Vá¬ 
rios dos termos contidos nesta seção fazem parte do contexto da 

ITIL. 

□ Requisitos gerais para um sistema de gestão de serviços : esta seção 
especializa requisitos que também são encontrados em outras normas 
ISO para o foco do Sistema de Gestão de Serviços: 
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A Responsabilidade da Direção : estabelece a importância do com¬ 
prometimento da Alta Administração com as atividades de desen¬ 
volvimento, implementação e melhoria do Sistema de Gestão de 
Serviços da organização, do estabelecimento de uma política de 
gerenciamento de serviços, da definição de autoridades e responsa¬ 
bilidades, além da designação de um representante da direção para 
o sistema. 

A Governança de processos operados por outras partes : estabelece a 
necessidade de que o provedor demonstre governança sobre pro¬ 
cessos que estejam sendo operados por outras partes (grupos in¬ 
ternos, clientes, fornecedores etc.), o que deve ocorrer por meio 
de processos como o Gerenciamento do Nível de Serviço e o Ge¬ 
renciamento de Fornecedores. 

A Gerenciamento da documentação : estabelece a necessidade de 
criar, manter e controlar documentos e registros que garantam a 
efetividade do planejamento, da operação e do controle do geren¬ 
ciamento de serviço, tais como políticas, planos, acordos de nível 
de serviço, procedimentos etc. 

A Gerenciamento de recursos : estabelece a necessidade do provi¬ 
mento de recursos humanos, técnicos, financeiros e de informa¬ 
ção para o SGS. No caso dos recursos humanos, reforça a impor¬ 
tância da definição das competências necessárias para a operação 
do SGS, enfatizando a importância de ações de desenvolvimento 
profissional e de conscientização acerca dos papéis e das responsa¬ 
bilidades junto aos colaboradores. 

A Estabelecimento e melhoria do SGS : define o escopo do SGS 
e aborda a aplicação do ciclo de melhoria contínua ( Plan-Do - 
Check-Act) sobre uma abordagem integrada dos processos de ge¬ 
renciamento de serviços, conforme mostra a Figura 7.11. 
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Figura 7.11: Metodologia Plan-Do-Check-Act, na visão da ISO/IEC 20000 
Adaptado de ABNT (2011) 


□ Desenho e transição de serviços novos ou modificados : esta cláusula 
visa assegurar que serviços novos e/ou mudanças em serviços possam 
ser planejados, desenhados, desenvolvidos, entregues e gerenciados, 
considerando aspectos como escopo, orçamento, alocação de recur¬ 
sos, níveis de serviço e processos já existentes etc. Neste ponto, perce- 
be-se um total alinhamento com as práticas de desenho de serviços e 
transição de serviços da ITIL 2011. 

□ Processos de entrega de serviço : esta seçáo descreve a abordagem da 
norma para os processos relacionados à entrega de serviços: 

A Gerenciamento do nível de serviço : visa definir, acordar, registrar 
e gerenciar níveis de serviço, abordando elementos importantes 
como o catálogo de serviços e os acordos de nível de serviço. 

A Relatos de serviço : visa a geraçáo de relatórios contendo informa¬ 
ções claras, confiáveis e concisas sobre o gerenciamento de serviço, 
de forma a subsidiar, no tempo adequado, a tomada de decisões e 
a comunicação entre todos os envolvidos. 
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A Gerenciamento da continuidade e disponibilidade do serviço : 

visa garantir que os compromissos assumidos junto aos clientes 
em relação à continuidade e à disponibilidade do serviço possam 
ser cumpridos em todas as circunstâncias, abordando a importân¬ 
cia de ações de monitoração, planejamento e testes. 

A Orçamento e contabilização para serviços 71 : abrange políticas e 
processos para orçamento e contabilização dos componentes en¬ 
volvidos no gerenciamento de serviços de TI (ativos, recursos 
compartilhados, serviços externos, pessoal, licenças etc.), alocação 
de custos diretos e indiretos aos serviços e controles e autorizações 
financeiras. 

A Gerenciamento da capacidade : visa garantir que o provedor de 
serviço tenha sempre capacidade suficiente para atender às de¬ 
mandas atuais e futuras, em conformidade com as necessidades 
de negócio do cliente. 

A Gerenciamento da segurança da informação : com total alinha¬ 
mento à norma ISO/IEC 17799, este processo visa gerenciar efe¬ 
tivamente a segurança da informação em todas as atividades do 
serviço, abordando a avaliação de riscos para os ativos conforme 
sua criticidade, o estabelecimento de controles para garantir a 
segurança e a disponibilidade da informação e o tratamento de 
mudanças e incidentes de segurança, em conformidade com os 
requisitos de segurança exigidos pelo negócio. 

□ Processos de relacionamento : descrevem os aspectos do relaciona¬ 
mento do provedor de serviços dentro da cadeia de valor que engloba 
a prestação do serviço, ou seja, com os clientes que recebem o ser¬ 
viço e com seus demais fornecedores de produtos, recursos e outros 
serviços: 

A Gerenciamento de relações de negócio : visa o estabelecimento e a 
manutenção de um bom relacionamento com os clientes, basea¬ 
do no entendimento das diretrizes de negócio, abordando ações 
como revisões regulares do serviço, processo de tratamento de re¬ 
clamações e medição da satisfação do cliente. 


71 Por ser considerada uma atividade opcional, a cobrança (integrante do processo de Gerenciamento 
Financeiro para Serviços de TI, da ITIL) não é coberta pela norma ISO/IEC 20000. 
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A Gerenciamento de fornecedores 72 : visa garantir a provisão de 
serviços aos clientes com qualidade e transparência, através do 
gerenciamento da cadeia completa de fornecedores (diretos e sub¬ 
contratados), abordando o gerenciamento dos contratos desde o 
início até a rescisão, dos níveis de serviço estabelecidos e dos even¬ 
tuais conflitos de interesses. 

□ Processos de resolução : englobam os processos de gerenciamento 
de incidentes, requisições de serviço e de problemas, assim como 
a sua priorização e o estabelecimento e a manutenção de soluções 
de contorno. 

A Gerenciamento de incidentes e requisições de serviço : visa restau¬ 
rar o nível de serviço acordado o mais rápido possível, ou respon¬ 
der a requisições de serviço, enfatizando o tratamento diferencia¬ 
do que deve ser dado aos incidentes mais críticos. 

A Gerenciamento de problemas : visa minimizar a interrupção do 
negócio através da identificação proativa (prevenção) e do geren¬ 
ciamento dos problemas durante todo o seu ciclo de vida, englo¬ 
bando registro, classificação, identificação da causa raiz, resolu¬ 
ção, comunicação, acompanhamento e encerramento. 

□ Processos de controle : englobam os processos que tratam os compo¬ 
nentes dos serviços e das mudanças pelas quais estes passam ao longo 
do tempo. 

A Gerenciamento da configuração : visa definir e controlar os com¬ 
ponentes do serviço e da infraestrutura relacionada, mantendo 
atualizadas as informações de sua configuração, englobando ati¬ 
vidades de planejamento, identificação dos itens de configuração, 
controle das alterações e da situação de cada item no seu ciclo de 
vida (desde a aquisição até o descarte) e auditoria das informações 
de configuração. 

A Gerenciamento de mudanças : visa garantir que todas as mu¬ 
danças sejam avaliadas adequadamente, aprovadas pelas ins¬ 
tâncias necessárias, implementadas conforme o seu planeja¬ 
mento e revisadas em relação ao atingimento dos objetivos, à 


72 A seleção e a contratação de fornecedores não são cobertas pela norma ISO/IEC 20000. 
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satisfação dos clientes e à existência de efeitos colaterais após a 
sua implantação. 

A Gerenciamento de liberação e implantação : abrange o estabeleci¬ 
mento de uma política para liberação de mudanças, assim como 
o planejamento integrado, a criação das unidades de liberação, os 
testes de aceitação, a documentação, a distribuição, a instalação e 
a avaliação pós-liberação, incluindo também ações de reversão ou 
correção em caso de falha. 


7.2.4 Aplicabilidade do modelo 

Devido ao alto grau de aderência, a norma ISO/IEC 20000 pode ser vista 
como um instrumento para certificar uma organização de TI quanto à efeti¬ 
vidade do seu processo de implementação do gerenciamento de um (ou mais) 
serviço (s) de TI, sob a ótica das práticas da ITIL. 

O escopo para esta adoção deve ser estabelecido conforme a estratégia da 
organização, podendo abranger desde um serviço específico dentro de uma 
das operações, até a totalidade dos serviços prestados. Analogamente à ITIL, 
recomenda-se que a certificação seja feita de forma gradual, partindo de um 
escopo reduzido de operações como piloto e posteriormente estendendo a 
certificação para as demais operações. 

A norma ISO/IEC 20000 é aplicável a organizações cuja missão envolve o 
fornecimento de serviços de TI para seus clientes, sejam estes externos (como 
no caso das empresas especializadas em serviços de TI) ou internos (áreas ou 
departamentos de TI dentro de empresas). Operações baseadas em cadeias de 
fornecimento de serviços (com fornecedores principais, subcontratados etc.) 
e que requerem processos consistentes e padronizados em todos os seus elos 
também poderão ser focadas por esta norma, uma vez que ela abrange o ge¬ 
renciamento dos contratos e dos níveis de serviço em consonância com os 
requisitos do negócio. 

Em suma, organizações que visam prover o mercado de serviços de TI de 
forma consistente, segura, padronizada e continuamente monitorada e me¬ 
lhorada são potenciais aspirantes à certificação em relação à norma. Por ser 
um padrão internacional, a ISO/IEC 20000 pode servir como base para com¬ 
paração com as melhores práticas do mercado e para avaliações independentes 
das operações. 
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A norma ISO/IEC 20000 pode ser adotada em conjunto com a ISO 9001, 
especializando os requisitos relativos à realização do produto (item 7) dentro 
do contexto do gerenciamento de serviços de TI. Isso significa que organi¬ 
zações que já possuem um sistema de gestão da qualidade bem estruturado 
poderão avaliar as possibilidades de reaproveitamento de alguns de seus ativos 
de processos e de informação já existentes para os esforços de preparação para 
a adoção da ISO/IEC 20000. 

Cabe também ressaltar que, no mercado brasileiro, várias empresas estão 
incluindo, em suas RFPs (Requests for Proposals ) para contratação de serviços, 
requisitos relacionados à padronização e à utilização das melhores práticas de 
mercado para gerenciamento de serviços de TL Operações que souberem de¬ 
monstrar consistentemente a sua habilidade para prover serviços que atendam 
aos requisitos de negócio dos clientes, e para gerenciá-los buscando sempre a 
sua melhoria contínua, poderão ter na certificação ISO/IEC 20000 um fator 
qualificador adicional para a sua pontuação. 


7.2.5 Benefícios do modelo 

Para uma organização de TI, a opção pela certificação dos processos de 
gerenciamento de serviços na norma ISO/IEC 20000 poderá trazer, além da¬ 
queles relacionados à adoção da ITIL (já enumerados neste livro), benefícios 
tais como: 

□ Demonstração clara de confiabilidade e consistência nos serviços de 
TI, atributos cruciais para a sobrevivência do negócio e para o seu 
potencial crescimento. 

□ Melhoria na comunicação interna, devido à maior proximidade e si¬ 
nergia entre a alta administração e as equipes que atuam no gerencia¬ 
mento dos serviços de TI. 

□ Maior comprometimento por parte de todas as áreas e profissionais 
envolvidos, devido ao estabelecimento claro de responsabilidades pe¬ 
los processos. 

□ Aumento da produtividade das equipes, devido ao estabelecimento 
de políticas e processos que precisam ser conhecidos por todos os 
envolvidos. 
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□ Melhor aproveitamento das habilidades dos profissionais envolvidos 
nos processos, em sintonia com as competências requeridas para a sua 
execução. 

□ Estabelecimento de uma cultura formal de melhoria contínua dos 
serviços de TI, sempre alinhada às necessidades do negócio e dos 
clientes. 

□ Redução do time-to-market de novos serviços e de modificações nos 
serviços existentes. 

□ Maior previsibilidade para os resultados dos serviços, dada a ênfase 
que a norma atribui às atividades de planejamento e orçamento. 

□ Maior acurácia dos relatórios de serviços, subsidiando com maior 
precisão a tomada de decisões relacionadas ao negócio. 

□ Entrega dos serviços de TI para o cliente com maior transparên¬ 
cia e uniformidade, através de mecanismos de integração da cadeia 
de fornecimento, englobando tanto fornecedores diretos como 
subcontratados. 

□ Maior efetividade no controle dos riscos relacionados à operação dos 
serviços. 

□ Melhoria da imagem da organização de TI e da qualidade percebida 
dos seus serviços por parte de seus clientes e fornecedores. 

□ Possibilidade de estabelecimento de um sistema integrado de gestão, 
através da operação conjunta com outras normas, tais como a ISO 
9001:2000 e a ISO/IEC 17799. 

□ Estabelecimento de um mecanismo para educação e aumento da 
conscientização das equipes através das auditorias regulares de 
certificação. 

□ A certificação obtida através de auditores qualificados e indepen¬ 
dentes pode ser considerada uma referência no mercado, em rela¬ 
ção à utilização das melhores práticas de gerenciamento de serviços 
de TI. 

Analogamente aos demais modelos de qualidade, a adoção da ISO/IEC 
20000 não garante que os serviços de TI prestados por uma organização cer¬ 
tificada sejam isentos de problemas ou proporcionem o retorno financeiro 
desejado, mas estabelece um alicerce consistente para que os serviços de TI 
possam estar cada vez mais alinhados aos requisitos de negócio. 
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7.2.6 Certificações relacionadas 

7.2.6.1 Foco organizacional 

A certificação de uma organização de TI nos requisitos da norma ISO/IEC 
20000 deve ser obtida através de uma auditoria independente, a ser condu¬ 
zida por um organismo independente credenciado para esta finalidade, de¬ 
nominado RCB ( Registered Certification Body ). Além do certificado oficial de 
conformidade, a organização certificada ganha o direito de utilização do logo 
oficial da norma em suas peças de marketing e de ter seu nome incluído em 
um web site exclusivo 73 . 

O processo de preparação para a certificação deve ser conduzido como 
um projeto formal, que deve ter como premissa o patrocínio e o compro¬ 
metimento da alta administração da organização com o seu sucesso. Entre as 
atividades e tarefas recomendadas para este projeto, destacam-se: 

□ Definição clara do escopo da certificação, ou seja, qual(is) serviço(s) 
e/ou operação(ões) da organização estará(ão) sujeita(s) à verificação 
de aderência aos requisitos da norma. 

□ Estabelecimento de uma equipe para conduzir o projeto, com um co¬ 
ordenador formal e devidamente treinada na interpretação da norma 
e nos princípios de gerenciamento de serviços de TI. 

□ Realização de uma análise prévia dos processos atuais (gap analysis ) 
para identificar o grau de aderência aos requisitos da norma, como 
subsídio para o planejamento das ações de melhoria dentro do 
projeto. 

□ Execução de ações corretivas e preventivas sobre os processos relacio¬ 
nados ao gerenciamento de serviços de TI, visando corrigir as defi¬ 
ciências e mitigar os riscos potenciais existentes. 

□ Capacitação dos colaboradores envolvidos com os serviços e opera¬ 
ções integrantes do escopo de certificação, acerca dos processos de 
gerenciamento de serviços de TI. 

□ Realização de auditorias internas para avaliação do progresso do 
projeto. 


73 Atualmente, o esquema de certificação organizacional para a ISO/IEC 20000, anteriormente 
gerenciado pelo itSMF International, é operado pelo APM Group. 
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□ Estabelecimento e reforço permanente da cultura de melhoria 
contínua, utilizando as náo conformidades encontradas e as ações 
corretivas correspondentes como alavancadores motivacionais dos 
colaboradores. 

O projeto termina com as atividades formais de pré-auditoria (opcio¬ 
nal) e de auditoria de certificação, realizadas pelo organismo certificador 
selecionado. 

Ainda não existem métricas oficiais para estimativa de prazo e custo de 
um projeto de certificação, pois esta depende de fatores intangíveis, tais 
como o nível de conformidade atual, a qualidade e o detalhamento da do¬ 
cumentação existente, e o tamanho e a complexidade da operação escolhida 
como escopo. 

No Brasil, atualmente, já existem várias empresas certificadas na ISO/ 
IEC 20000 e muitas outras organizações que estão com seus projetos de 
preparação para certificação em andamento. Em geral, os organismos certi- 
ficadores são os mesmos que realizam auditorias em relação às demais nor¬ 
mas ISO. 


7.2.6.2 Foco individual 

Existem atualmente dois esquemas direcionados às certificações indivi¬ 
duais relacionadas à norma ISO/IEC 20000: 

□ EXIN. 

□ APM Group. 

O EXIN tem utilizado a ISO/IEC 20000 como direcionador para as 
suas certificações em Gerenciamento de Serviços de TI. Seu esquema de 
certificação possui uma estrutura sustentada por um exame de fundamentos 
e fortalecida por uma camada intermediária de certificações: cinco delas no 
nível profissional (das quais três delas devem ser obtidas) e, opcionalmente, 
uma no nível associado). A partir deste ponto, o profissional pode seguir 
duas carreiras distintas: a de consultor/gerente (com duas certificações) e/ 
ou a de auditor interno (uma certificação). Existe ainda uma certificação 
“ponte” de fundamentos para aqueles que possuem a certificação de Funda¬ 
mentos ITIL. 
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A Figura 7.12 ilustra o esquema de certificação do EXIN. 
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Figura 7.12: Esquema de certificação do EXIN 
Fonte: site do EXIN (www.exin.com) 


Já o esquema de certificação do APM Group possui três certificações: 

□ ISO/IEC 20000 - Foundation: avalia o conhecimento dos candida¬ 
tos sobre o conteúdo e os requisitos da norma. 

□ ISO/IEC 20000 - Practitioner. testa a habilidade dos candidatos 
em aplicar o conteúdo da norma em organizações certificadas ou que 
estão buscando a certificação. 
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□ ISO/IEC 20000 - Auditor: avalia o entendimento dos candidatos 
acerca dos princípios do Gerenciamento de Serviços de TI, do con¬ 
teúdo e dos requisitos da norma. 

Para ambos os esquemas de certificação descritos, há empresas no Brasil 
credenciadas para aplicar treinamentos e exames. 


7.3 CMMI for Services 

O CMMI-SVC tem o propósito de ser um guia para a implantação das 
melhores práticas do CMMI para organizações provedoras de serviços, sendo 
que essas melhores práticas estão focadas nas atividades para fornecer serviços 
com qualidade para os clientes e usuários finais. 

Este modelo, em sua versão 1.3, de 2010, exibe a mesma estrutura do 
CMMI for Development e adota o mesmo esquema de certificação, de ma¬ 
turidade e capacidade. Foi desenvolvido levando em consideração o próprio 
CMMI e outros modelos como ITIL, CobiT, ISO/IEC 20000 e o Informa¬ 
tion Technology Services Capability Model - ITSCMM. 

O CMMI-SVC é composto por 24 áreas de processos específicas e um 
conjunto de práticas genéricas alocadas conforme os níveis de maturidade da 
representação por estágios e compartilha algumas áreas de processo do CMMI 
for Development. 

As tabelas 7.3, 7.4, 7.5 e 7.6 apresentam uma breve descrição de cada uma 
das áreas de processo, conforme os níveis de maturidade. 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 2 

Gestão da confiquração 
(CM) 

Estabelecer e manter a integridade dos produtos de trabalho 
usando a identificação de configuração, controle da configuração, 
o status da configuração e as auditorias de configuração. 

Medição e análise (MA) 

Desenvolver e sustentar uma capacidade de medição usada 
para apoiar as necessidades de informações gerenciais. 

Garantia da qualidade do 
processo e produto (PPQA) 

Fornecer ao pessoal de serviços e à gerência avaliações objetivas 
acerca dos processos e dos produtos de trabalho associados. 

Gestão de requisitos (RM) 

Gerenciar os requisitos de produtos e dos componentes dos 
produtos e assegurar o alinhamento entre eles e os requisitos 
dos planos e produtos de trabalho. 
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Nível 2 

Gestão do acordo com o 
fornecedor (SAM) 

Gerenciar a aquisição de serviços e produtos de fornecedores. 


Entrega do serviço (SD) 

Entregar os serviços de acordo com os acordos com os clientes. 


Controle e monitoração do 
trabalho (WMC) 

Fornecer um entendimento do trabalho que está sendo 
executado, de forma que ações corretivas possam ser tomadas 
quando o desempenho desvia significativamente do plano. 


Planejamento do trabalho 
(WP) 

Estabelecer e manter planos para definir as atividades do trabalho. 


Tabela 7.3 - CMMI-SVC - Processos do nível 2 
Adaptado de SEI (2010c) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 3 

Gestão da capacidade e 
disponibilidade (CAM) 

Assegurar o desempenho efetivo do sistema de serviço 
e assegurar que os recursos são fornecidos e usados 
efetivamente para apoiar os requisitos dos serviços. 


Análise e resolução de 
decisão (DAR) 

Analisar possiveis decisões usando um processo formal de 
avaliação que analisa alternativas identificadas contra critérios 
estabelecidos. 


Resolução e prevenção 
de incidentes (IRP) 

Assegurar a resolução efetiva e no tempo acordado de 
incidentes de serviços, assim como a prevenção de incidentes 
de forma apropriada. 


Gestão integrada do 
trabalho (IWM) 

Estabelecer e gerenciar o trabalho e o envolvimento de 
interessados relevantes de acordo com processos definidos 
e integrados, que sejam “customizáveis” a partir do conjunto 
padrão de processos. 


Definição do processo 
organizacional (OPD) 

Estabelecer e manter um conjunto de ativos de processos 
organizacionais, tais como padrões do ambiente de trabalho, 
regras e guias de orientação para as equipes. 


Foco no processo 
organizacional (OPF) 

Planejar, implementar e entregar melhorias nos processos 
organizacionais com base no completo entendimento dos pontos 
fortes e fracos dos processos e ativos de processos da organização. 


Treinamento 
organizacional (OT) 

Desenvolver habilidades e conhecimentos de pessoas de forma 
que elas possam desempenhar seus papéis de maneira efetiva 
e eficaz. 


Gestão de riscos (RSKM) 

Identificar os problemas potenciais antes que eles ocorram, 
de forma que as atividades de riscos possam ser planejadas 
e acionadas quando necessário ao longo do ciclo de vida do 
produto ou trabalho, visando mitigar impactos adversos no 
atendimento aos objetivos. 


Continuidade do serviço 
(SCON) 

Estabelecer e manter planos para assegurar a continuidade dos 
serviços durante qualquer interrupção das operações normais. 
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Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 3 

Desenvolvimento do 
sistema de serviços (SSD) 

Analisar, projetar, desenvolver, integrar, verificar e validar 
sistemas de serviços, incluindo os componentes do sistema de 
serviço, para satisfazer acordos de serviços existentes ou futuros. 

Transição do sistema do 
serviço (SST) 

Entregar novas ou significantes mudanças nos componentes 
do sistema de serviços enquanto gerencia o seu impacto nos 
serviços em execução. 

Gestão estratégica do 
serviço (STSM) 

Estabelecer e manter padrões de serviços de acordo com as 
necessidades estratégicas e dos planos. 


Tabela 7.4 - CMMI-SVC - Processos do nível 3 
Adaptado de SEI (2010c) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 4 

Desempenho do processo 
organizacional (OPP) 

Estabelecer e manter um entendimento quantitativo 
do desempenho de processos selecionados, no 
conjunto de processos da organização, em apoio 
ao atendimento dos objetivos de qualidade e de 
desempenho do processo e fornecer dados de 
desempenho, baselines e modelos para gerenciar 
quantitativamente o trabalho. 

Gestão quantitativa do trabalho 
(QWM) 

Gerenciar quantitativamente o trabalho para atender 
aos objetivos de qualidade e desempenho do processo 
estabelecido para o trabalho. 


Tabela 7.5 - CMMI-SVC - Processos do nível 4 
Adaptado de SEI (2010c) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 5 

Gestão do desempenho 
organizacional (OPM) 

Gerenciar proativamente o desempenho da organização 
para atender aos objetivos do negócio. 

Análise e resolução de causas 
(CAR) 

Identificar causas de resultados selecionados e tomar 
ações para melhorar o desempenho do processo. 


Tabela 7.6 - CMMI-SVC - Processos do nível 5 
Adaptado de SEI (2010c) 
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Os principais benefícios do CMMI-SVC podem ser distribuídos pelos es¬ 
tágios de maturidade atingidos por uma organização de serviços, como mos¬ 
tra a Tabela 7.7. 


Nível de Maturidade 

Benefícios 

2 - Gerenciado 

• 0 serviço é gerenciado e entregue conforme o planejado. 

• 0 serviço atende aos requisitos do cliente. 

• Os acordos com os clientes e fornecedores são gerenciados. 

• 0 provedor de serviços adquire a capacidade de medir o desempenho do serviço. 

• Recursos estão disponíveis para a execução dos serviços. 

• Os processos são mantidos em períodos de pico de demanda. 

3 - Definido 

• O provedor de serviço emprega processos definidos. 

• 0 serviço tem garantias de continuidade e disponibilidade. 

• 0 serviço tem capacidade de expansão planejada. 

• Os processos são melhorados continuamente. 

• Processos podem ser adaptados para atender a situações específicas. 

• Ganhos de produtividade à medida que os ativos de processos são gerenciados. 

4 - Gerenciado 
Quantitativamente 

• Os processos são gerenciados a partir de objetivos de desempenho. 

• A qualidade e o desempenho do processo são compreendidos de forma estatística. 

• O desempenho do processo é entendido e previsível. 

• A capacidade do processo é compreendida. 

5 - Otimizado 

• Os processos são melhorados continuamente com o entendimento dos objetivos 
do negócio e as necessidades de desempenho. 

• A organização compreende as causas de variação nos processos. 

• Os processos são melhorados continuamente e através de inovações. 

• Os resultados das melhorias são analisados quando ao seu efeito no 
desempenho do processo. 

• O foco é sobre a melhoria da organização como um todo. 


Tabela 7.7- Benefícios do CMMI-SVC 
Adaptado de SEI (2010c) 


Este modelo é, de certa forma, equivalente à ISO/IEC 20000, em termos 
de certificação para um provedor de serviço. Entretanto, é bem mais rigoro¬ 
so quando considerados os níveis 4 e 5 de maturidade (melhoria contínua 
efetiva e permanente). Requer, naturalmente, uma grande mudança cultural 
da organização, que pode ser conseguida ao longo do tempo, à medida que a 
organização vai adquirindo maturidade. 

Todavia, no contexto do mercado brasileiro, os provedores de serviços es¬ 
tão atualmente optando pela obtenção da certificação ISO/IEC 20000. 










282 Implantando a Governança de TI - 4 a edição 


7.4 MR-MPS Serviços 

7.4.1 Histórico do modelo 

O SOFTEX, Associação para a Promoção da Excelência do Software Brasi¬ 
leiro, além de ter promovido o desenvolvimento do MR-MPS para software, 
desenvolveu esforços que culminaram na publicação, em 2012, do modelo 
para serviços. 

O Modelo de Referência MR-MPS-SV foi elaborado com base nos seguin¬ 
tes frameworks-, 

□ O modelo de referência MR-MPS-SV [SOFTEX (2012a)]. 

□ A norma internacional ISO/IEC 20000:2011. 

□ A norma internacional ISO/IEC 15504. 

□ O modelo CMMI-SVC - Capability Model Integration for Services. 

O modelo é composto por: 

□ Guia Geral MPS de Serviços. 

□ Guia de Avaliação. 

□ Guias de Implementação (ainda focados no software). 

O principal motivador, de acordo com SOFTEX (2012a), foi a crescente 
pressão sobre os provedores de serviços quanto à qualidade dos serviços pres¬ 
tados, sendo que, na maioria das vezes, os provedores de serviços trabalham de 
forma reativa, com pouco esforço para planejamento, treinamento, análises 
críticas e trabalho com o cliente. 

A ideia é que o MR-MPS-SV possa ser usado para a melhoria das práticas 
de serviços de forma a criar condições de maior competitividade dos provedo¬ 
res de serviços no Brasil e também internacionalmente. 

Os focos do modelo são as micro, pequenas e médias empresas. 

De acordo com SOFTEX (2012a), “o modelo MPS baseia-se nos concei¬ 
tos de maturidade e capacidade de processo para a avaliação e melhoria da 
qualidade e produtividade de software e serviços correlatos e também para a 
melhoria da qualidade e produtividade dos serviços prestados ”. 
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7.4.2 Objetivos do modelo 

Uma das metas do programa MPS.BR, segundo SOFTEX (2012a), é: 
“definir e aprimorar um modelo de melhoria e avaliação de processo de 
software e serviços, visando preferencialmente às micro, pequenas e mé¬ 
dias empresas, de forma a atender às suas necessidades de negócio e ser 
reconhecido nacional e internacionalmente como um modelo aplicável à 
indústria de software e serviços. O modelo MPS estabelece dois modelos 
de referência de processos de software e serviços e um processo/método de 
avaliação de processos. Esta estrutura fornece sustentação e garante que o 
modelo MPS seja empregado de forma coerente com as suas definições. 
O modelo MPS estabelece também um modelo de negócio para apoiar a 
sua adoção pelas empresas desenvolvedoras de software e prestadores de 
serviços”. 


7.4.3 Estrutura do modelo 

7.4.3.1 Visão geral do modelo 

O modelo MPS é formado pelos seguintes componentes: 

□ Modelo de Referência (MR-MPS-SW), composto por um Guia Ge¬ 
ral que o descreve, por um Guia de Aquisição de software e serviços 
correlatos e um conjunto de Guias de Implementação focados em 
cada um dos seus sete níveis de maturidade e também em organiza¬ 
ções específicas (que adquirem software, Fábricas de Software e Fá¬ 
bricas de Testes). 

□ Modelo de Referência (MR-MPS-SV), composto por um Guia Geral 
que o descreve. 

□ Método de Avaliação (MA-MPS), contendo requisitos para os avalia¬ 
dores líderes, avaliadores adjuntos e instituições avaliadoras. 

□ Modelo de Negócio (MN-MPS), descrevendo regras de negócio ge¬ 
rais para implementação, avaliação, organização de grupos de empre¬ 
sas, certificação de consultores e programas de treinamento. 
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A Figura 7.13 mostra a estrutura na qual o Modelo de Referência (MR- 
-MPS-SV) está baseado. Os elementos desta estrutura serão abordados nas 
seções a seguir. 



Figura 7.13 - Estrutura do MR-MPS, mostrando seus principais elementos 
Adaptado de SOFTEX (2012a) 


7.4.3.2 Os níveis de maturidade 

Assim como acontece no CMMI-SVC, os níveis de maturidade do modelo 
MPS estabelecem patamares de evolução dos processos e representam estágios 
de melhoria para a implementação de processos em uma organização. 

A cada nível de maturidade estão associados um conjunto de processos 
e um conjunto de atributos de processos cujo atendimento é necessário. 
Isso significa que, para alcançar um determinado nível de maturidade do 
MR-MPS-SV, os objetivos e resultados esperados dos processos devem ser 
atendidos, e os resultados esperados dos atributos de processo estabelecidos 
para aquele nível também devem ser atendidos. 

O MR-MPS-SV possui sete níveis de maturidade, conforme mostra a Ta¬ 
bela 7.8: 














Modelos para Gerenciamento de Serviços de TI 285 


A 

Em Otimização 

B 

Gerenciado Quantitativamente 

C 

Definido 

D 

Largamente Definido 

E 

Parcialmente Definido 

F 

Gerenciado 

G 

Parcialmente Gerenciado 


Tabela 7.8 - Níveis de maturidade do MR-MPS 
Fonte: SOFTEX (2012a) 


7.4.3.3 Os processos do MR-MPS-SV 

O MR-MPS-SV possui 26 processos, distribuídos entre os níveis de ma¬ 
turidade. Isso significa que cada processo está associado ao primeiro nível de 
maturidade que tenha como requisito o atendimento a algum de seus atribu¬ 
tos de processo. De acordo com SOFTEX (2012a), os processos são: 

□ Nível G - Parcialmente Gerenciado : o nível de maturidade G é com¬ 
posto pelos processos Entrega de Serviços, Gerência de Incidentes, 
Gerência de Nível de Serviço, Gerência de Requisitos e Gerência de 
Trabalhos. Neste nível a implementação dos processos deve satisfazer 
os atributos de processo AP 1.1 e AP 2.1. 

A Entrega de Serviços (ETS): o propósito é entregar os serviços em 
conformidade com os acordos de serviços. 

A Gerência de Incidentes (GIN): o propósito é restaurar os servi¬ 
ços acordados e cumprir as solicitações de serviços dentro de um 
Acordo de Nível de Serviço (ANS). 

A Gerência de Nível de Serviço (GNS): o propósito é garantir que 
os objetivos dos acordos de nível de serviço para cada cliente se¬ 
jam atendidos. 

A Gerência de Requisitos (GRE): o propósito é gerenciar os re¬ 
quisitos de trabalho e dos componentes de trabalho e identificar 
inconsistências entre os requisitos, os planos de trabalho e os pro¬ 
dutos de trabalho. 
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A Gerência de Trabalhos (GTR): o propósito é estabelecer e man¬ 
ter planos que definem atividades, recursos e responsabilidades 
do trabalho a ser realizado, bem como prover informações sobre 
o seu andamento que permitam a realização de correções quando 
houver desvios significativos em seu desempenho. O propósito 
deste processo evolui à medida que a organização cresce em matu¬ 
ridade. Assim, a partir do nível E, alguns resultados evoluem e ou¬ 
tros são incorporados, de forma que a gerência de trabalhos passe 
a ser realizada com base no processo definido para o trabalho e 
nos planos integrados. No nível B, a gerência de trabalhos passa a 
ter um enfoque quantitativo, refletindo a alta maturidade que se 
espera da organização. Novamente, alguns resultados evoluem e 
outros são incorporados. 

□ Nível F - Gerenciado : o nível de maturidade F é composto pelos pro¬ 
cessos do nível de maturidade anterior (G) acrescidos dos processos 
Aquisição, Gerência de Configuração, Garantia da Qualidade, Ge¬ 
rência de Problemas, Gerência de Portfólio de Trabalhos e Medição. 
Neste nível, a implementação dos processos deve satisfazer os atribu¬ 
tos de processo AP 1.1, AP 2.1 e AP 2.2. 

A Aquisição (AQU): o propósito é gerenciar a aquisição de serviços e 
produtos que satisfaçam as necessidades expressas pelo adquirente. 
A Gerência de Configuração (GCO): o propósito é estabelecer e 
manter a integridade de todos os produtos de trabalho de um 
processo ou trabalho e disponibilizá-los a todos os envolvidos. 

A Garantia da Qualidade (GQA): o propósito é assegurar que os 
produtos de trabalho e a execução dos processos estejam em con¬ 
formidade com os planos, procedimentos e padrões estabelecidos. 
A Gerência de Problemas (GPL): o propósito é minimizar a inter¬ 
rupção do serviço por meio da investigação da causa raiz de um 
ou mais incidentes que impactam nos serviços ou nos acordos de 
nível de serviço. 

A Gerência de Portfólios de Trabalho (GPT): o propósito é iniciar 
e manter trabalhos que sejam necessários, suficientes e sustentá¬ 
veis, de forma a atender aos objetivos estratégicos da organização. 
Este processo compromete o investimento e os recursos organiza- 
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cionais adequados e estabelece a autoridade necessária para execu¬ 
tar os trabalhos selecionados. Ele executa a qualificação contínua 
de trabalhos para confirmar que eles justificam a continuidade 
dos investimentos ou podem ser redirecionados para justificar. 

A Medição (MED): o propósito é coletar, armazenar, analisar e re¬ 
latar os dados relativos aos serviços desenvolvidos e aos processos 
implementados na organização e em seus trabalhos, de forma a 
apoiar os objetivos organizacionais. 

□ Nível E - Parcialmente Definido : o nível de maturidade E é com¬ 
posto pelos processos dos níveis de maturidade anteriores (G e F), 
acrescidos dos processos Avaliação e Melhoria do Processo Organi¬ 
zacional, Definição do Processo Organizacional, Gerência de Mu¬ 
danças e Gerência de Recursos Humanos. O processo Gerência de 
Trabalhos sofre sua primeira evolução, retratando seu novo pro¬ 
pósito: gerenciar o trabalho com base no processo definido para o 
trabalho e nos planos integrados. Neste nível a implementação dos 
processos deve satisfazer os atributos de processo AP 1.1, AP 2.1, 
AP 2.2, AP 3.1 e AP 3.2. 

A Avaliação e Melhoria do Processo Organizacional (AMP): o 

propósito é determinar o quanto os processos padrão da organiza¬ 
ção contribuem para alcançar os objetivos de negócio da organi¬ 
zação e para apoiar a organização a planejar, realizar e implantar 
melhorias contínuas nos processos com base no entendimento de 
seus pontos fortes e fracos. 

A Definição do Processo Organizacional (DFP): o propósito é 
estabelecer e manter um conjunto de ativos de processo organi¬ 
zacional e padrões do ambiente de trabalho usáveis e aplicáveis às 
necessidades de negócio da organização. 

A Gerência de Mudanças (GMU): o propósito é assegurar que to¬ 
das as mudanças que afetam os trabalhos sejam avaliadas, aprova¬ 
das, implementadas e revisadas de maneira controlada. 

A Gerência de Recursos Humanos (GRH): o propósito é prover 
a organização e os trabalhos com os recursos humanos necessá¬ 
rios e manter suas competências adequadas às necessidades do 
negócio. 
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□ Nível D - Largamente Definido : o nível de maturidade D é com¬ 
posto pelos processos dos níveis de maturidade anteriores (G ao E), 
acrescidos dos processos Desenvolvimento do Sistema de Serviços e 
Orçamento e Contabilização para Serviços. Neste nível a implemen¬ 
tação dos processos deve satisfazer os atributos de processo AP 1.1, 
AP 2.1, AP 2.2, AP 3.1 e AP 3.2. 

A Desenvolvimento do Sistema de Serviços (DSS): o propósito é 
analisar, projetar, desenvolver, integrar, verificar e validar o siste¬ 
ma de serviços, incluindo os componentes, para satisfazer acordos 
existentes ou previstos. 

A Orçamento e Contabilização de Serviços (OCS): o propósito é 
controlar o orçamento e a contabilização dos serviços fornecidos. 

□ Nível C - Definido : o nível de maturidade C é composto pelos pro¬ 
cessos dos níveis de maturidade anteriores (G ao D), acrescidos dos 
processos Gerência de Capacidade, Gerência da Continuidade e Dis¬ 
ponibilidade dos Serviços, Gerência de Decisões, Gerência de Libe¬ 
ração, Gerência da Segurança da Informação, Gerência de Riscos e 
Relato de Serviços. Neste nível a implementação dos processos deve 
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e 
AP 3.2. 

A Gerência de Capacidade (GCA): o propósito é assegurar que o 
provedor de serviços tenha capacidade para atender aos requisitos 
atuais e futuros acordados. 

A Gerência de Continuidade e Disponibilidade dos Serviços 

(GCD): o propósito é assegurar que acordos de níveis de serviços 
sejam cumpridos em circunstâncias previsíveis. 

A Gerência de Decisões (GDE): o propósito é analisar possíveis 
decisões críticas usando um processo formal, com critérios estabe¬ 
lecidos, para avaliação das alternativas identificadas. 

A Gerência de Liberação (GLI): o propósito é implantar liberações 
e componentes de serviços em um ambiente de produção de for¬ 
ma controlada. 

A Gerência de Riscos (GRI): o propósito é identificar, analisar, tra¬ 
tar, monitorar e reduzir continuamente os riscos em nível organi¬ 
zacional e de trabalho. 
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A Gerência da Segurança da Informação (GSI): o propósito é ge¬ 
renciar a segurança da informação em um acordo de nível de segu¬ 
rança dentro de todas as atividades do gerenciamento do serviço. 

A Relatos de Serviços (RLS): o propósito é produzir relatórios 
pontuais e precisos para apoiar uma efetiva comunicação e toma¬ 
da de decisão. 

□ Nível B - Gerenciado Quantitativamente : 

A Este nível de maturidade é composto pelos processos dos níveis 
de maturidade anteriores (G ao C). Neste nível o processo de Ge¬ 
rência de Trabalhos sofre sua segunda evolução, sendo acrescenta¬ 
dos novos resultados para atender aos objetivos de gerenciamento 
quantitativo. 

A Neste nível a implementação dos processos deve satisfazer os atri¬ 
butos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 e os 
RAPs 22 a 25 do AP 4.1. 

A A implementação dos processos selecionados para análise de de¬ 
sempenho deve satisfazer integralmente os atributos de processo 
AP 4.1 e AP 4.2. 

A Este nível não possui processos específicos. 

□ Nível A — Em Otimização : 

A Este nível de maturidade é composto pelos processos dos níveis 
de maturidade anteriores (G ao B). Neste nível, a implementação 
dos processos deve satisfazer os atributos de processo AP 1.1, AP 
2.1, AP 2.2, AP 3.1, AP 3.2 e os RAPs 22 a 25 do AP 4.1. 

A A implementação dos processos selecionados para análise de de¬ 
sempenho deve satisfazer integralmente os atributos de processo 
AP 4.1 e AP 4.2. 

A Os atributos de processo AP 5.1 e AP 5.2 devem ser integralmen¬ 
te satisfeitos pela implementação de pelo menos um dos processos 
selecionados para análise de desempenho. 

A Este nível não possui processos específicos. 
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7.4.3.4 Os atributos de processos do MR-MPS-SV 

A capacidade de um processo, no MR-MPS, reflete o grau de refinamento 
e institucionalização com que este processo é executado na organização. Esta 
capacidade é representada por um conjunto de atributos de processo descritos 
em termos de resultados esperados. À medida que a organização evolui nos 
níveis de maturidade, um maior grau de capacidade deve ser atingido na exe¬ 
cução do processo. 

O MR-MPS possui nove atributos de processos, conforme mostra a Ta¬ 
bela 7.9: 


Atributo de Processo 

Mede o quanto... 

Exemplos de resultados esperados 74 

AP1.1 -0 processo é 
executado 

o processo atinge o seu propósito. 

RAP 1 - 0 processo atinge seus resultados 
definidos 

AP2.1 -0 processo é 
gerenciado 

a execução do processo é 
gerenciada. 

RAP 2 - Existe uma política organizacional 
estabelecida e mantida 

RAP 3 - A execução do processo é planejada 
RAP 4 - (para o nível G) - A execução 
do processo é monitorada e ajustes são 
realizados 

RAP 5 - As informações e os recursos 
necessários para a execução do processo 
são identificados e disponibilizados 

AP2.2 - Os produtos de 
trabalho do processo são 
gerenciados 

os produtos de trabalho produzidos 
pelo processo são gerenciados 
apropriadamente. 

RAP 11 - Os requisitos dos produtos de 
trabalho do processo são identificados 

RAP 12 - Requisitos para documentação 
e controle dos produtos de trabalho são 
estabelecidos 

RAP 13 - Os produtos de trabalho são 
colocados em níveis apropriados de controle 

AP3.1 -0 processo é 
definido 

um processo padrão é mantido 
para apoiar a implementação do 
processo definido. 

RAP 15 - Um processo padrão é descrito, 
incluindo diretrizes para sua adaptação 

RAP 16 - A sequência e a interação do 
processo padrão com outros processos são 
determinadas 

AP3.2 - 0 processo está 
implementado 

o processo padrão é efetivamente 
implementado como um processo 
definido para atingir seus 
resultados. 

RAP 19 - Um processo definido é 
implementado baseado nas diretrizes para 
seleção e/ou adaptação do processo padrão 
RAP 20 - A infraestrutura e o ambiente 
de trabalho requeridos para executar o 
processo definido são disponibilizados, 
gerenciados e mantidos 


74 São 46 os resultados esperados. Na tabela são apresentados apenas alguns. Se desejar ter acesso 
ao Guia do MR-MPS-SV e conhecer os demais RAPs, consulte a página www.softex.org.br. 
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Atributo de Processo 

Mede o quanto... 

Exemplos de resultados esperados 

AP4.1 -0 processo é 
medido 

os resultados de medição são 
usados para assegurar que a 
execução do processo atinge os 
seus objetivos de desempenho e 
apoia o alcance dos objetivos de 
negócio definidos. 

RAP 22 - As necessidades de informação 
dos usuários dos processos, requeridas 
para apoiar objetivos de negócio relevantes 
da organização, são identificadas 

RAP 23 - Objetivos de medição 
organizacionais dos processos e/ 
ou subprocessos são derivados das 
necessidades de informação dos usuários 
do processo 

AP4.2 - 0 processo é 
controlado 

o processo é controlado 
estatisticamente para produzir 
um processo estável, capaz 
e previsível dentro de limites 
estabelecidos. 

RAP 30 - Técnicas de análise e de controle 
para a gerência quantitativa dos processos/ 
subprocessos são identificadas e aplicadas 
quando necessário 

AP5.1 -0 processo é 
objeto de melhorias e 
inovações 

as mudanças no processo 
são identificadas a partir da 
análise de defeitos, problemas, 
causas comuns de variação do 
desempenho e da investigação 
de enfoques inovadores para a 
definição e implementação do 
processo. 

RAP 35 - Objetivos de negócio da 
organização são mantidos com base no 
entendimento das estratégias de negócio e 
resultados de desempenho do processo 

AP5.2 - 0 processo é 
otimizado continuamente 

as mudanças na definição, 
gerência e desempenho do 
processo têm impacto efetivo para 
o alcance dos objetivos relevantes 
de melhoria do processo. 

RAP 43-0 impacto de todas as mudanças 
propostas é avaliado com relação aos 
objetivos do processo definido e do 
processo padrão 

RAP 46 - Dados da análise de causas e de 
resolução são armazenados para uso em 
situações similares 


Tabela 7.9 - Atributos de processo do MR-MPS 
Fonte: SOFTEX (2012a) 


Para atingir um nível de maturidade, é esperado que todos os proces¬ 
sos relativos a este nível atendam aos resultados esperados dos próprios 
processos, assim como os resultados esperados dos atributos dos processos 
correspondentes àquele nível (e também aos processos de todos os níveis 
anteriores). 

Por exemplo: uma organização que atinge o nível F atende a todos os atri¬ 
butos de processo dos níveis G e F, para todos os processos correspondentes 
ao nível de maturidade F (que compreende também o nível G). Ao atingir o 
nível F, os processos do nível de maturidade G devem ser executados com um 
nível de capacidade. 
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A Tabela 7.10 mostra, para cada nível de maturidade do MR-MPS, os 
seus processos, os atributos de processo que precisam ser atingidos por 
cada processo, além de uma equivalência com os níveis de maturidade do 
CMMI-DEV. 


Nível de 

Maturidade 

Processos do Nível de Maturidade 

Atributos de Processo 
Correspondentes 

A 


AP 1.1, AP 2.1, AP 2.2, AP 3.1, 
AP 3.2, AP 4.1, AP 4.2, AP 5.1 
e AP 5.2 

B 

• Gerência de trabalhos (evolução) 

AP 1.1, AP 2.1, AP 2.2, AP 3.1 
e AP 3.2, AP 4.1 e AP 4.2 

C 

• Gerência de Capacidade - GCA 

• Gerência da Continuidade e Disponibilidade dos 

Serviços - GCD 

• Gerência de Decisões - GDE 

• Gerência de Liberação - GLI 

• Gerência de Riscos - GRI 

• Gerência da Segurança da Informação - GSI 

• Relato de Serviços - RLS 

AP 1.1, AP 2.1, AP 2.2, AP 3.1 
e AP 3.2 

D 

• Desenvolvimento do Sistema de Serviços - DSS 

• Orçamento e Contabilização de Serviços - OCS 

AP 1.1, AP 2.1, AP 2.2, AP 3.1 
e AP 3.2 

E 

• Avaliação e Melhoria do Processo Organizacional - AMP 

• Definição do Processo Organizacional - DFP 

• Gerência de Mudanças - GMU 

• Gerência de Recursos Humanos - GRH 

• Gerência de Trabalhos - GTR (evolução) 

AP 1.1, AP 2.1, AP 2.2, AP 3.1 
e AP 3.2 

F 

• Aquisição - AQU 

• Gerência de Configuração - GCO 

• Garantia da Qualidade - GQA 

• Gerência de Problemas - GPL 

• Gerência de Portfólio de Trabalhos - GPT 

• Medição - MED 

AP 1.1, AP 2.1 e AP 2.2 

G 

• Entrega de Serviços - ETS 

• Gerência de Incidentes - GIN 

• Gerência de Nível de Serviço - GNS 

• Gerência de Requisitos - GRE 

• Gerência de Trabalhos-GTR 

AP 1.1 e AP 2.1 


Tabela 7.10 - Níveis de maturidade do MR MPS, seus atributos de processo correspondentes 

Fonte: SOFTEX (2012a) 
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7.4.4 Aplicabilidade do modelo 

O MR-MPS-SV pode ser implementado em quaisquer organizações que 
tenham foco em serviços (sejam elas internas a uma empresa ou fornecedores 
externos). 

A divisão em sete níveis de maturidade permite que seja possível imple¬ 
mentar, avaliar e melhorar os processos (para o atendimento dos atributos de 
processos) em prazos mais curtos e de forma mais gradual. Este fato configura 
uma situação bastante adequada para as micro, pequenas e médias empre¬ 
sas provedoras de serviços, devido aos menores custos de implementação e 
avaliação e à possibilidade de atingir resultados de melhoria de processos e 
maturidade em intervalos menores de tempo. 

A implementação de um modelo de maturidade nos moldes do MR-MPS- 
-SV pode ser um diferencial para tais organizações, diante das exigências cada 
vez maiores apresentadas pelos clientes em suas RFIs (Requests for Informa- 
tions ) e RFPs (Request for Proposals ) para contratação de serviços, sejam em¬ 
presas privadas e órgãos e empresas governamentais. 

Apesar do foco do modelo estar mais direcionado às pequenas e médias 
empresas, o modelo também é plenamente aplicável a organizações de maior 
tamanho, sejam elas públicas ou privadas. 

Este modelo começa a ser procurado pelas empresas brasileiras provedoras 
de serviços, a partir de programas de fomento à melhoria da qualidade de 
software e serviços promovidos pela SOFTEX. Em alguns casos, várias em¬ 
presas se associam para contratar em conjunto serviços de consultoria especia¬ 
lizada na implementação do modelo. 

Além das organizações que têm interesse em utilizar o MR-MPS-SV 
para a melhoria dos serviços, outras empresas também fazem parte des¬ 
te ecossistema, tendo participação atuante nos esforços de preparação e 
avaliação: 

□ Instituições Implementadoras (II), credenciadas para prestar servi¬ 
ços de consultoria de implementação do modelo. 

□ Instituições Avaliadoras (IA), credenciadas para prestar serviços se¬ 
gundo o método de avaliação MA-MPS. 
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7.4.5 Certificações relacionadas 

Neste modelo, as avaliações serão conduzidas por uma Instituição creden¬ 
ciada para Avaliação - IA (Instituição Avaliadora), e a implantação poderá 
ser realizada por uma Instituição credenciada para Implantação (Instituição 
Implementadora). 

O processo de avaliação do modelo MPS envolve atividades, tais como: 

□ Contratar a avaliação (pesquisar instituições avaliadoras e estabelecer 
um contrato). 

□ Preparar a realização da avaliação (viabilizar, planejar e preparar a 
avaliação, conduzir a avaliação inicial, completar a preparação da 
avaliação). 

□ Realizar a avaliação final (conduzir a avaliação final e avaliar a execu¬ 
ção do processo de avaliação). 

□ Documentar os resultados da avaliação (relatar e registrar os resultados). 

A avaliação de maturidade do modelo MPS deve ser realizada por uma 
equipe composta por membros internos (representantes da unidade organi¬ 
zacional) e membros externos (avaliador líder, avaliadores adjuntos da Insti¬ 
tuição Avaliadora e, opcionalmente, avaliadores em formação indicados pela 
SOFTEX). A duração da avaliação e a quantidade (mínima e máxima) de 
avaliadores são proporcionais à capacidade exigida para cada nível de maturi¬ 
dade. Uma avaliação pode durar de um a cinco dias, e contar com uma equipe 
de três a nove avaliadores. 

A avaliação tem validade por dois anos. Ao final desses dois anos, a em¬ 
presa deverá passar por nova avaliação para manter a maturidade adquirida já 
avaliada ou evoluir o nível de maturidade. 

Neste modelo, empresas em regime de cooperativa também podem ser 
avaliadas conjuntamente. 
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7.5 USMBOK™ 

7.5.1 Objetivos do modelo 

O USMBOK™ {Universal Service Management Body ofKnowledgé) consis¬ 
te em um conjunto de publicações e referências destinadas a profissionais que 
trabalham em organizações provedoras de serviços que necessitam desenvol¬ 
ver práticas centradas nos clientes, com base em experiências bem-sucedidas 
de prestação de serviços. Uma das características mais interessantes deste mo¬ 
delo é o fato de contemplar princípios da disciplina de Gerenciamento de 
Serviços aplicáveis em qualquer organização provedora de serviços (inclusive 
as que prestam serviços de TI). 

Este modelo tem sido desenvolvido de forma continuada desde o início 
dos anos 90 pela empresa Service Management 101 75 . Além do Guia para o 
USMBOK™, estão disponíveis as seguintes publicações: 

□ USMBOKLexicon : glossário contendo os termos mais comuns (mais 
de 1.200) utilizados nas demais publicações do USMBOK. 

□ Guias de prática para os processos de Gerenciamento de Incidentes , 
Gerenciamento de Problemas , Gerenciamento de Mudanças e Ge¬ 
renciamento da Configuração . 

□ Outside In Method™ \ descrição dos conceitos e métodos associados 
a um modo de pensar centrado no cliente, detalhando passo a passo 
como eles podem ser aplicados em um negócio de serviços e como 
parte de uma iniciativa de gerenciamento de serviços. 


7.5.2 Estrutura do modelo 

De acordo com Clayton (2012), o sucesso das iniciativas de gerenciamento 
de serviços não depende somente do núcleo de conhecimento universal sobre 
Gerenciamento de Serviços, mas também de competências em outras áreas 
de conhecimento e fontes de informações relacionadas, conforme mostra a 
Tabela 7.11: 


75 Maiores detalhes podem ser encontrados no sítio http://www.servicemanagement101 .com . 
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Áreas de Conhecimento Relacionadas 

Fontes de Informações Relacionadas 

• Liderança 

• Gerenciamento de Operações 

• Gerenciamento da Qualidade 

• Desenvolvimento e Gerenciamento de Recursos 

• Gerenciamento de Produtos 

• Medição, Análise e Melhoria 

• Indústria de Serviços 

• Ambiente Organizacional 

• Governança, Riscos e Compliance 

• Normas Nacionais e Internacionais 

• Corpos de conhecimento relacionados 

• Frameworks de Gerenciamento de Programas e 
Projetos 


Tabela 7.11 - Áreas de conhecimento e fontes de informações 
relacionadas à disciplina de Gerenciamento de Serviços 
Adaptado de Clayton (2012) 


Este núcleo de conhecimento universal, materializado na publicação The 
Guide to the Universal Service Management Body of Knowledge (Clayton, 
2012), é descrito na forma de um Framework de Gerenciamento de Serviços, 
ilustrado na Figura 7.14: 



Figura 7.14 - Framework de Gerenciamento de Serviços do USMBOK™ 
Adaptado de Clayton (2012) 
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O framework proposto pelo USMBOK™, de acordo com Clayton (2012), 
é composto por seis elementos principais: 

□ O Produto de Serviço representa a oferta, o mercado consumidor e 
as estratégias de entrega e suporte necessárias para o fornecimento, 
sendo normal. Uma forma muito comum de representá-lo é o termo 
“8 Ps” (Produto, Localização, Promoção, Preço, Processo, Produtivi¬ 
dade, Pessoas e Evidência Física 76 ). 

□ O Sistema de Gestão de Serviços suporta a oferta, a solicitação, a re¬ 
alização e o suporte do produto de serviço, assim como a gestão dos 
denominados “4 Es” relacionados aos momentos de interação com o 
consumidor (Encontro, Expectativa, Experiência e Emoções), tendo 
as Requisições de Serviço como entradas. 

□ A parte humana do Sistema de Gestão de Serviços é a Organiza¬ 
ção Provedora de Serviços, que compreende e descreve domínios 
de conhecimento, papéis e responsabilidades e atores que desem¬ 
penham ações na linha de frente ou de retaguarda e que interagem 
com processos de suporte, sistemas de informação e elementos da 
infraestrutura. 

□ O Sistema de Gestão da Força de Trabalho assegura que a equipe 
da Organização Provedora de Serviços esteja focada, motivada e 
adequadamente recompensada, e que o esforço seja gerenciado de 
maneira eficiente através de ordens de trabalho com ciclo de vida 
definido. 

□ O Sistema de Gestão de Consumidores assegura que o Produ¬ 
to de Serviço e o Sistema de Gestão de Serviços funcionem em 
alinhamento com as necessidades do consumidor e com os pla¬ 
nos da Organização Provedora de Serviços, utilizando para tal 
um conjunto de métodos para gerenciar o relacionamento com os 
consumidores. 

□ O Sistema para Excelência de Serviços atua como um programa de 
melhoria contínua com foco na excelência operacional dos serviços, 
tendo como entradas chaves itens como documentos de visão e es- 


76 “Localização” e “Evidência Física” são traduções livres dos autores para os termos P/ace e Physical 
Evidence. 
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copo, medições operacionais e gerenciais, relatos de problemas, re¬ 
clamações e oportunidades, e, como saídas, iniciativas na forma de 
ações de manutenção (mudanças) adaptativas, corretivas, preventivas 
e perfectivas, dentro de um plano de revisão. 


7.5.3 Aplicabilidade e benefícios do modelo 

De forma análoga à ITIL, o USMBOK™ apresenta conceitos e práticas 
compatíveis com várias modalidades de prestação de serviços, com inúme¬ 
ras possibilidades de aplicação, não somente nas organizações de TI, mas em 
qualquer estrutura organizacional cujo objetivo seja a prestação de serviços a 
clientes/consumidores, sejam eles internos ou externos à empresa. 

Nesse sentido, fornece uma referência de fundamentos para vários perfis 
de profissionais que lidam com a disciplina de Gerenciamento de Serviços, 
tais como: 

□ Membros da alta administração. 

□ Gerentes de programas e gerentes de organizações provedoras de 
serviços. 

□ Gerentes de serviços e outros profissionais responsáveis por portfólios 
de serviços. 

□ Contratantes e consumidores (usuários/clientes) de serviços. 

□ Gerentes funcionais cujos funcionários possuem responsabilidades 
específicas relativas a serviços. 

□ Pesquisadores, instrutores e educadores na disciplina de Gerencia¬ 
mento de Serviços. 

□ Consultores e especialistas na disciplina e em assuntos relacionados. 

□ Profissionais interessados em preparar uma organização provedora de 
serviços para uma avaliação e/ou certificação em competências cha¬ 
ves, ou para uma auditoria de conformidade em relação a alguma 
norma ou conjunto de regulações. 

Ainda não há pesquisas específicas acerca da utilização do USMBOK™ 
em âmbito corporativo, e a sua divulgação no Brasil encontra-se ainda 
em estágio inicial. Entretanto, os conceitos e as práticas nele contidos 
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(notadamente sua abordagem centrada no cliente - o método Outside In) 
possuem um altíssimo potencial para auxiliar organizações provedoras de 
serviços a criar um Framework de Gerenciamento de Serviços que efeti¬ 
vamente assegure a entrega de valor aos clientes por meio da prestação de 
serviços. 

O USMBOK™ pode ser utilizado em conjunto com modelos como ITIL 
e CobiT, sendo totalmente compatível com as normas ISO 9000 e ISO/IEC 
20000 - 1 . 

7.5.4 Certificações relacionadas 

Desde novembro de 2012, o EXIN disponibiliza para o público uma certi¬ 
ficação denominada USMBOK Foundation, que visa avaliar o entendimento 
da teoria de gerenciamento de serviços, assim como da terminologia básica, 
dos princípios e conceitos encontrados na disciplina de Gerenciamento Uni¬ 
versal de Serviços. 

O exame para esta certificação possui cem questões objetivas a serem res¬ 
pondidas em um prazo de duas horas, com índice mínimo de 80% de acer¬ 
tos. A consulta ao Guia para o USMBOK™ é permitida, mas apenas em sua 
versão impressa. 


7.6 Microsoft Operations Framework (MOF) 

- UMA BREVE VISÃO 

O MOF é o modelo criado pela Microsoft para gestão de serviços de TI e é 
baseado no modelo ITIL, através da adoção, adaptação e combinação do seu 
conjunto de melhores práticas ao ambiente Microsoft. A sua quarta edição foi 
publicada em 2008. 

O MOF tem como objetivo orientar os profissionais na criação, implemen¬ 
tação e gestão de serviços de forma eficaz e com boa relação custo-benefício. 
Para isso, organiza suas atividades (inclusive as revisões gerenciais da operação) 
e processos em Funções de Gerenciamento de Serviços, que estão agrupadas 
em fases que compõem um ciclo de vida de serviço. A Figura 7.15 mostra as 
fases deste ciclo de vida. 
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Figura 7.15 - Ciclo de vida de serviço do MOF 


□ Fase “Planejar” : suas práticas asseguram o alinhamento com os 
objetivos de negócio e de TI, a conformidade com as políticas 
vigentes, o gerenciamento financeiro e a confiabilidade da entre¬ 
ga dos serviços. Nesta fase são sugeridas Revisões Gerenciais para 
verificar o alinhamento dos serviços e a adequação ao portfólio de 
serviços. 

□ Fase “Entregar” : suas práticas visam apoiar os profissionais na cria¬ 
ção, estabilização e implantação de serviços de TI, aplicações e 
melhorias na infraestrutura da forma mais eficiente possível. Nes¬ 
ta fase são sugeridas Revisões Gerenciais para aprovar o plano do 
projeto e verificar a prontidão para a transição para entrada em 
produção. 

□ Fase “Operar” : suas práticas visam assegurar que os serviços implan¬ 
tados sejam operados, mantidos e suportados de maneira alinhada 
com os Acordos de Nível de Serviço estabelecidos entre o negócio e a 
TI. Nesta fase é sugerida uma Revisão Gerencial para verificar a saúde 
operacional dos serviços. 
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□ Camada “Gerenciar” : esta camada é a fundação para as demais fases do 
ciclo de vida, pois estabelece uma abordagem integrada e coordenada 
para as atividades de Gerenciamento de Serviços de TI, apoiando os 
profissionais a gerenciar aspectos de governança, riscos e conformi¬ 
dade (GRC), mudanças e configuração, e a estabelecer equipes ágeis, 
flexíveis e com alto grau de compreensão de suas responsabiidades. 
Nela é sugerida uma Revisão Gerencial para verificar o atendimento 
aos requisitos da política de serviços. 

A certificação MOFFoundation (conhecimento básico nos fundamentos 
do modelo) é oferecida pelo EXIN. 

Para maiores detalhes, consulte o site do MOF (www.microsoft.com/mof). 





Modelos para Pr ocessos de Software 


Provavelmente os processos de software sejam aqueles para os quais mais 
modelos de melhores práticas foram desenvolvidos ao longo dos anos. Entre 
esses modelos, figuram técnicas de engenharia de software, metodologias e 
padrões para as várias etapas do desenvolvimento, adaptações de métodos de 
gerenciamento de projetos etc. 

Entretanto, o que tem ficado cada vez mais evidente é que os processos de 
software precisam ser tratados de forma integrada e interdisciplinar, ou seja, 
abrangendo aspectos técnicos de engenharia, de gerenciamento de projetos e 
operações de sustentação, de controle de artefatos e de gerenciamento de re¬ 
quisitos náo funcionais, notadamente daqueles relacionados à infraestrutura. 
Abordagens integradas dessa natureza estão presentes nos modelos de maturi¬ 
dade criados para avaliar e acreditar as organizações de software. 

Neste capítulo, são apresentados de forma resumida os princípios e proces¬ 
sos de dois modelos de maturidade que têm sido utilizados como base de boas 
práticas para processos de software: o CMMI (na modalidade para o processo 
de Desenvolvimento) e o MR-MPS (modelo brasileiro para melhoria do pro¬ 
cesso de software); e citaremos brevemente as normas ISO/IEC 12207 e ISO/ 
IEC 9126, também aplicáveis a processos de software. 


8.1 CMMI 

8.1.1 Histórico do modelo 


A partir de uma encomenda feita pelo DoD (Departamento de Defesa 
norte-americano), o SW-CMM (Capability Maturity Model para Software) 
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foi criado em 1991 pelo Software Engineering Institute (SEI), da Carnegie 
Mellon University (CMU), como um modelo de qualidade para o processo de 
engenharia de software. O mercado de empresas de software havia, então, en¬ 
contrado nele uma de suas principais referências como modelo de qualidade. 

As diferentes necessidades das organizações originaram variações aplicáveis 
a outras disciplinas, tais como engenharia de sistemas, aquisição de software, 
gestão e desenvolvimento de mão de obra e desenvolvimento integrado de 
produtos e processos. Entretanto, cada um desses modelos possuía sua própria 
arquitetura e abordagem de implementação, o que dificultava a sua utilização 
por organizações com processos integrados envolvendo várias dessas discipli¬ 
nas, devido aos altos custos de treinamento, avaliação e ações de melhoria. 

Diante deste cenário, o CMMI {Capabilily Maturity Model Integralion) foi 
criado pelo SEI em 2002 como um modelo evolutivo em relação aos vários 
CMMs, com o objetivo de combinar as suas várias disciplinas em uma estru¬ 
tura única, flexível e componentizada que pudesse ser utilizada de forma in¬ 
tegrada por organizações que demandavam processos de melhoria em âmbito 
corporativo. Além da integração, o modelo tornou mais claros alguns aspectos 
que antes eram implícitos, tais como a diferenciação entre os conceitos de 
“organização” e “empresa”, a valorização dos processos de “verificação” e “vali¬ 
dação” e a evolução da característica “Medição e Análise” (comum a todas as 
KPAs do CMM) para se tornar uma importante Área de Processo do CMMI. 

Em agosto de 2006, o SEI publicou a versão 1.2 do CMMI, incorpo¬ 
rando uma série de melhorias e simplificações em relação à versão anterior. 
Entre elas, estão a unificação do tratamento das disciplinas de engenharia de 
software, engenharia de sistemas, desenvolvimento integrado de produto e 
processo e terceirização em um só documento, denominado “CMMI para 
Desenvolvimento”, e a adoção de uma nova arquitetura para o modelo (inspi¬ 
rada no conceito de “constelações”) que permitisse a sua expansão para outros 
focos, tais como aquisições e entrega de serviços. 

O SEI publicou, em novembro de 2010, a versão 1.3 do CMMI, in¬ 
cluindo melhorias significativas, tais como o refinamento das áreas de pro¬ 
cesso dos níveis mais altos de maturidade para refletir outros modelos de 
melhores práticas do mercado (tais como métodos ágeis, Lean Seis Sigma 
etc.), a simplificação do seu modelo de arquitetura e maior clareza nos 
termos do glossário. A principal mudança foi a eliminação das metas e 
práticas genéricas dos níveis 4 e 5 de maturidade, assim como dos níveis 
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de capacitação 4 e 5, uma vez que a aplicação dos níveis 1 a 3 nas áreas de 
processo dos maiores níveis de maturidade tem se mostrado suficiente para 
os objetivos de qualidade do modelo. 

8.1.2 Objetivos do modelo 

O principal propósito do CMMI é fornecer diretrizes baseadas em me¬ 
lhores práticas para a melhoria dos processos e habilidades organizacionais, 
cobrindo o ciclo de vida de produtos e serviços completos, nas fases de con¬ 
cepção, desenvolvimento, aquisição, entrega e manutenção. Nesse sentido, 
suas abordagens envolvem a avaliação da maturidade da organização ou a 
capacitação das suas áreas de processo, o estabelecimento de prioridades e a 
implementação de ações de melhoria. 


8.1.3 Estrutura do modelo 

8.1.3.1 Visão geral do modelo 

Cada organização possui o seu próprio modus operandi e, consequente¬ 
mente, uma forma particular de gerenciar mudanças nos seus processos orga¬ 
nizacionais. Essa realidade, assim como o fato de que existem organizações de 
diversos tamanhos, é contemplada pelo CMMI, que oferece duas abordagens 
distintas para a sua implementação: a Abordagem por Estágios e a Aborda¬ 
gem Contínua. Atendendo a requisitos de componentização, a versão 1.3 
do CMMI apresenta tais abordagens reunidas em um mesmo documento, 
dentro do escopo de cada “constelação”. 

Uma constelação é uma coleção de componentes gerada a partir do frame- 
work CMMI, que engloba um modelo fundamental, seus materiais de trei¬ 
namento e documentação relacionada a avaliações, abrangendo uma área de 
interesse específica. A expansão das constelações para conteúdos específicos 
adicionais é feita através de “adições”. As seguintes constelações (que são com¬ 
plementares entre si) fazem parte do escopo da versão 1.3 do CMMI 77 : 


77 Neste capítulo, será abordada apenas a constelação CMMI-DEV, devido à sua aplicabilidade aos 
processos de software. As demais constelações serão brevemente abordadas no capítulo sobre modelos 
para sourcing. 
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□ CMMI para Desenvolvimento (CMMI-DKV) : provê diretrizes para 
monitorar, mensurar e gerenciar processos de desenvolvimento. 

□ CMMI para Serviços (CMMI-SVC) : provê diretrizes para entrega de 
serviços dentro das organizações e para clientes externos. 

□ CMMI para Aquisições (CMMI-ACQ) ; provê diretrizes para suporte 
às decisões relacionadas à aquisição de produtos e serviços. 

Os principais componentes da estrutura do CMMI estão representados na 
Figura 8.1 e definidos a seguir: 



Figura 8.1 - Componentes da estrutura do CMMI-DEV 
Fonte: SEI (2010b) 


□ Áreas de Processo : conjunto de práticas inter-relacionadas que, quan¬ 
do executadas coletivamente, satisfazem um conjunto de metas consi¬ 
deradas importantes para realizar melhorias significativas em uma de¬ 
terminada área (possuem, como subcomponentes informativos, um 
objetivo, notas introdutórias e outras áreas de processo relacionadas). 

□ Metas Específicas : metas relacionadas a uma determinada área de 
processo que descrevem o que deve ser realizado para assegurar que 
esta esteja efetivamente implementada. 
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□ Práticas Específicas : descrições das atividades consideradas importan¬ 
tes para o atendimento de suas respectivas metas específicas. Podem 
ser detalhadas em subpráticas e possuem como saídas os produtos de 
trabalho típicos. 

□ Metas Genéricas : metas comuns, compartilhadas por múltiplas áreas 
de processo, que, quando atingidas dentro de uma área de processo 
específica, podem indicar se estáo sendo planejadas e implementadas 
de forma efetiva, replicável e controlada. 

□ Práticas Genéricas : descrições das atividades consideradas importan¬ 
tes para o atingimento das suas respectivas metas genéricas e que ga¬ 
rantem a institucionalização efetiva, repetível e controlada das áreas 
de processo. As práticas genéricas podem ser divididas em subpráticas 
e conter derivações específicas (elaborações) relacionadas a cada área 
de processo em que são aplicadas. 

□ Componentes Informativos de Suporte : informações adicionais ne¬ 
cessárias para a descrição de um componente: 

A Notas: incluem detalhamento, fundamentação teórica ou restri¬ 
ções/premissas relacionadas ao componente. 

A Exemplos: texto ou lista de itens para melhor clarificar um con¬ 
ceito ou atividade descrita. 

A Referências: indicação de que há informações adicionais ou mais 
detalhadas para um componente na descrição de outras áreas de 
processo relacionadas. 

Os componentes do modelo CMMI também podem ser classificados em 
categorias que refletem o modo como devem ser interpretados: 

□ Requeridos : absolutamente necessários para a implementação de uma 
área de processo. Exemplos: Metas Específicas e Metas Genéricas. 

□ Esperados : compõem uma implementação típica de uma área de pro¬ 
cesso, porém aceitando alternativas que produzam resultados satisfa¬ 
tórios. Exemplos: Práticas Específicas e Práticas Genéricas. 

□ Informativos : auxiliam no entendimento detalhado das metas e 
práticas, e das formas como podem ser implementadas. Exemplos: 
subpráticas, notas, referências, exemplos de produtos de trabalho 


etc. 










Modelos para Processos de Software 307 


8.1.3.2 Áreas de processo 

Seguindo uma estrutura baseada no inter-relacionamento funcional en¬ 
tre as metas, dentro de uma visão de melhoria corporativa de processos, 
o CMMI sugere que as suas 22 áreas de processo sejam agrupadas em 
quatro categorias de afinidade (visando suportar a abordagem contínua de 
implementação): 

□ Gestão do Processo : agrupa áreas de processos que manipulam pro¬ 
cessos no âmbito da organização, permeando todos os projetos (ver 
Tabela 8.1). 


Área de Processo 

Objetivo 

Foco no Processo 
Organizacional (OPF) 

Planejar, implementar e entregar melhorias no processo organizacional 
(incluindo o processo padrão e os derivados de adaptações), com base no claro 
entendimento dos seus pontos fortes e fracos. 

Definição do Processo 
Organizacional (OPD) 

Estabelecer e manter uma biblioteca (re)utilizável de componentes do processo 
organizacional, incluindo políticas, descrições de processos, modelos de ciclos de 
vida, critérios e diretrizes para adaptação do processo, repositório de métricas e 
demais itens de documentação relacionados. 

Treinamento 
Organizacional (OT) 

Desenvolver as habilidades e o conhecimento das pessoas, de forma que elas 
possam desempenhar seus papéis no processo organizacional de forma efetiva. 

Desempenho 
do Processo 
Organizacional (OPP) 

Estabelecer e manter uma visão quantitativa do desempenho dos processos 
padrões e prover modelos e baselines de desempenho, visando melhorar a gestão 
dos projetos através de métricas de processo e produto. 

Gestão do Desempenho 
Organizacional (OPM) 

Gerenciar proativamente o desempenho da organização para atingir os seus 
objetivos de negócio. 


Tabela 8.1 - Áreas de processo da categoria “Gestão do Processo” 
Fonte: SEI (2010b) 


□ Gestão do Projeto : envolve áreas de processo que tratam aspectos de 
planejamento, monitoração e controle relacionados exclusivamente a 
projetos (ver Tabela 8.2). 













308 Implantando a Governança de TI - 4 a edição 


Área de Processo 

Objetivo 

Planejamento do 

Projeto (PP) 

Estabelecer e manter planos que definam as atividades dos projetos, envolvendo 
a elaboração de estimativas, o estabelecimento do nível adequado de interação 
com os grupos envolvidos e a obtenção de compromissos. 

Controle e Monitoração 
do Projeto (PMC) 

Permitir uma visibilidade adequada do progresso do projeto, de forma que possam 
ser tomadas ações corretivas apropriadas quando o seu desempenho apresentar 
desvios significativos em relação ao planejado (replanejamento, estabelecimento 
de novos acordos e/ou mitigação de riscos). 

Gestão do Acordo com 
o Fornecedor (SAM) 

Gerenciar a aquisição de produtos de fornecedores externos para os quais existe 
um acordo formal (produtos e/ou componentes entregáveis ao cliente, ou mesmo 
ferramentas e ambientes operacionais para o projeto). 

Gestão Integrada do 
Projeto (IPM) 

Planejar e gerenciar o projeto e o envolvimento dos principais grupos 
interessados, de acordo com um processo definido e integrado, derivado do 
processo padrão da organização. 

Gestão de Requisitos 
(REQM) 

Gerenciar os requisitos técnicos e não técnicos absorvidos ou gerados por um 
projeto, identificando as inconsistências em relação aos planos e produtos do 
projeto e tratando de forma adequada as mudanças necessárias e seus impactos. 

Gestão de Riscos 
(RSKM) 

Identificar problemas potenciais antes de sua ocorrência, para que possam ser 
planejadas e executadas ações de tratamento de riscos, visando a mitigação de 
impactos negativos nos objetivos, ao longo do ciclo de vida do projeto ou produto. 

Gestão Quantitativa do 
Projeto (QPM) 

Gerenciar quantitativamente (através de métricas) o processo definido do 
projeto, visando o atingimento dos objetivos preestabelecidos de desempenho de 
qualidade e processo. 


Tabela 8.2 - Áreas de processo da categoria “Gestão do Projeto” 

Fonte: SEI (2010b) 

□ Engenharia : agrupa áreas de processo 78 relacionadas ao ciclo de vida de 
desenvolvimento e manutenção de produtos, assim como à garantia do 
seu funcionamento e da sua aderência às especificações (ver Tabela 8.3). 


Área de Processo 

Objetivo 

Desenvolvimento de 
Requisitos (RD) 

Gerar, analisar, definir e validar requisitos do cliente, assim como seus 
desdobramentos para os requisitos do produto e dos seus componentes, em 
conformidade com as necessidades dos grupos interessados. 

Solução Técnica (TS) 

Projetar, desenvolver e implementar alternativas de soluções para o atendimento 
de requisitos preestabelecidos, podendo envolver a criação e/ou aquisição de 
produtos, componentes de produtos ou serviços relacionados. 


78 As áreas de processo “Integração do Produto”, “Verificação” e “Validação”, dentro do CMMI-DEV, 
possuem adições abrangendo testes de software, hardware e sistemas. 


















Modelos para Processos de Software 309 


Área de Processo 

Objetivo 

Integração do Produto 
(PI) 

Montar o produto a partir dos seus componentes e entregá-lo ao cliente, 
garantindo o seu funcionamento de forma integrada em relação a todas as 
interfaces internas e externas. 

Verificação (VER) 

Garantir que um determinado produto satisfaça os respectivos requisitos para os 
quais foi desenvolvido. 

Validação (VAL) 

Demonstrar que um determinado produto ou componente de produto atinge os 
resultados esperados depois de colocado em operação no ambiente final. 


Tabela 8.3 - Áreas de processo da categoria “Engenharia” 
Fonte: SEI (2010b) 


□ Suporte : qualifica processos cujas atividades são distribuídas ao longo 
de um projeto de desenvolvimento ou manutenção de produto, e 
cujos objetivos são atingidos indiretamente através da sua execução 
(ver Tabela 8.4). 


Área de Processo 

Objetivo 

Gestão da Configuração (CM) 

Estabelecer e manter a integridade dos produtos de trabalho através da 
identificação, do controle, da verificação e do monitoramento constante 
da situação da sua configuração. 

Garantia da Qualidade do 
Processo e do Produto (PPQA) 

Prover aos integrantes das equipes uma visibilidade mais clara 
do andamento dos processos e dos produtos gerados, através de 
avaliações objetivas em relação às especificações, da identificação de 
não conformidades e do acompanhamento de ações corretivas. 

Medição e Análise (MA) 

Desenvolver e manter uma capacitação de medição para suportar as 
necessidades de informações gerenciais, em termos de conceitos, 
técnicas e mecanismos de execução. 

Análise de Decisões e 

Resolução (DAR) 

Analisar possíveis decisões utilizando um processo de avaliação 
formal, que considera alternativas identificadas em relação a critérios 
preestabelecidos. 

Análise e Resolução de Causas 
(CAR) 

Identificar causas de defeitos e outros problemas e tomar ações 
corretivas para prevenir a sua ocorrência futura. 


Tabela 8.4 - Áreas de processo da categoria “Suporte” 
Fonte: SEI (2010b) 
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8.1.3.3 A abordagem de implementação por estágios 

Esta abordagem pode ser considerada uma evolução direta do CMM, 
uma vez que também é baseada em cinco níveis de maturidade: Inicial 
(1), Gerenciado (2), Definido (3), Gerenciado Ouantitativamente (4) e 
Otimizado (5). 

Um nível de maturidade pode ser considerado um degrau evolucionário 
para a melhoria do processo organizacional como um todo e consiste em prá¬ 
ticas específicas e genéricas que integram um conjunto predefinido de áreas de 
processo. O cumprimento das metas específicas e genéricas correspondentes 
a essas áreas de processo é um pré-requisito para o atingimento do nível de 
maturidade correspondente. 

A Figura 8.2 ilustra a inter-relaçáo entre os componentes estruturais do 
CMMI, conforme a abordagem por estágios: 


f " _ . h 



Figura 8.2 - Estrutura do CMMI na abordagem por estágios 
Adaptado de SEI (2010b) 


A Tabela 8.5 mostra as áreas de processo que precisam ser desenvolvidas para 
que cada um dos níveis de maturidade do CMMI seja atingido pela organização: 


Nível 5 
(Otimizado) 

• Gestão do Desempenho Organizacional (OPM) 

• Análise e Resolução de Causas (CAR) 

Nível 4 

(Gerenciado quantitativamente) 

• Desempenho do Processo Organizacional (OPP) 

• Gestão Quantitativa do Projeto (QPM) 
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Nível 3 
(Definido) 

• Desenvolvimento de Requisitos (RD) 

• Solução Técnica (TS) 

• Integração do Produto (PI) 

• Verificação (VER) 

• Validação (VAL) 

• Foco no Processo Organizacional (OPF) 

• Definição do Processo Organizacional (OPD) 

• Treinamento Organizacional (OT) 

• Gestão Integrada do Projeto (IPM) 

• Gestão de Riscos (RSKM) 

• Análise de Decisões e Resolução (DAR) 

Nível 2 
(Gerenciado) 

• Gestão de Requisitos (REQM) 

• Planejamento do Projeto (PP) 

• Controle e Monitoração do Projeto (PMC) 

• Gestão do Acordo com o Fornecedor (SAM) 

• Medição e Análise (MA) 

• Garantia da Qualidade do Processo e do Produto (PPQA) 

• Gestão da Configuração (CM) 


Tabela 8.5 - Áreas de processo por níveis de maturidade 


Cada nível de maturidade possui algumas características que mere¬ 
cem destaque e devem ser levadas em consideração nas suas iniciativas de 
implementação: 

□ Nível 2 (Gerenciado): 

A O foco é direcionado para práticas de gestão de projetos, indi¬ 
cando que, em uma organização ainda imatura, é mais priori¬ 
tário aprender a planejar, controlar e gerenciar os projetos do 
que investir em técnicas e metodologias de desenvolvimento de 
produtos. 

A Gerenciar projetos envolve gerenciar, durante o seu andamento, 
os requisitos estabelecidos junto aos grupos interessados, a qua¬ 
lidade e a integridade dos produtos gerados, a aderência aos pro¬ 
cessos existentes e os acordos formalizados com os fornecedores 
envolvidos. 

A Há uma preocupação explícita em relação à criação de uma infra- 
estrutura para medição e análise dos processos, para viabilizar o 
seu controle e gerenciamento efetivo. 
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□ Nível 3 (Definido): 

A O foco está no processo de engenharia de produtos, que espelha as 
fases de um ciclo de vida padrão: Concepção (“Desenvolvimento de 
Requisitos”), Análise e Desenho (“Solução Técnica”), Testes e Im¬ 
plantação (“Integração do Produto”, “Verificação” e “Validação”). 

A O modelo fomenta a criação de um ambiente organizacional 
orientado à integração entre equipes de trabalho e ao comparti¬ 
lhamento de conhecimentos e habilidades. 

A O estímulo a práticas de gestão de riscos e à tomada de decisão 
baseada em análises formais fortalece as responsabilidades e os 
compromissos assumidos. 

□ Nível 4 (Gerenciado Ouantitativamente): 

A A gestão quantitativa baseada em medições e indicadores cobre, 
de forma integrada, todo o conjunto de processos organizacionais, 
assim como os projetos e respectivos produtos, como instrumento 
de suporte para o atendimento dos objetivos de desempenho de 
processo e de qualidade. 

A Os projetos e seus produtos, assim como o processo organizacio¬ 
nal, são controlados estatisticamente. 

□ Nível 5 (Otimizado): 

A O conceito de inovação organizacional integra os processos de 
gestão de mudanças tanto em processos como na tecnologia. 

A A importância da análise e da resolução das causas dos desvios é 
explicitamente enfatizada. 


8.1.3.4 A abordagem contínua de implementação 

Através desta abordagem, o CMMI permite que cada uma de suas áreas 
de processo seja implementada de forma independente e evolutiva, agru¬ 
pando suas práticas genéricas e específicas em quatro níveis de capacidade: 

□ Nível 0 (Incompleto) : o processo não é executado ou é parcialmente 
executado, ou seja, uma (ou mais) das metas específicas de sua área de 
processo não é satisfeita. 







Modelos para Processos de Software 313 


□ Nível 1 (Executado) : o processo satisfaz todas as metas específicas de 
sua área de processo e realiza o trabalho necessário para gerar os seus 
produtos. 

□ Nível 2 (Gerenciado) : o processo é planejado e executado de acor¬ 
do com políticas organizacionais, utiliza pessoal habilitado e recursos 
adequados para gerar saídas de forma controlada e envolve os grupos 
interessados adequados, além de ser monitorado, controlado, revisa¬ 
do, avaliado quanto à conformidade com sua descrição e ao desem¬ 
penho previsto nos seus planos. 

□ Nível 3 (Definido) : o processo é gerenciado e adaptado a partir de um 
conjunto de processos padronizados da organização, que, por sua vez, 
também evoluem continuamente. 

Cada nível de capacidade tem apenas uma meta genérica que descreve o 
grau de institucionalização que a organização deve atingir no processo através 
das práticas genéricas relacionadas. 

A Figura 8.3 ilustra a inter-relaçáo entre os componentes estruturais do 
CMMI, conforme a abordagem contínua: 



Figura 8.3 - Estrutura do CMMI na abordagem contínua 
Adaptado de SEI (2010b) 
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Uma organização pode acompanhar a sua evolução na abordagem contí¬ 
nua do CMMI através de um perfil de níveis de capacidade, que consiste em 
uma visão das áreas de processo e dos seus respectivos níveis de capacitação, 
extraída em vários momentos dentro do programa de melhoria. 
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Esses perfis periódicos podem ser comparados a um perfil alvo que re¬ 
presente os objetivos de melhoria da organização. Os perfis alvo podem ser 
dispostos em sequência ao longo do tempo, de forma que a organização 
tenha objetivos sucessivos de melhoria, caracterizando uma estratégia de¬ 
nominada target staging. Ao adotar essa estratégia, deve-se atentar para o 
fato de que há interdependências entre as práticas genéricas e outras práti¬ 
cas ou áreas de processo e que uma prática genérica não poderá ser consi¬ 
derada implementada enquanto todas as suas dependências não estiverem 
atendidas. 


8.1.3.5 Equivalência entre as abordagens de implementação 

A opção pela abordagem contínua não exclui a possibilidade de utiliza¬ 
ção da abordagem por estágios. A organização poderá estabelecer perfis alvos 
para o atingimento dos próprios níveis de maturidade, através da estratégia de 
equivalent staging. Essa estratégia baseia-se em uma relação de equivalência, 
onde são estabelecidos os níveis de capacidade (NCs) que cada área de proces¬ 
so (AP) deve atingir na abordagem contínua, para que um determinado nível 
de maturidade (NMs, na abordagem por estágios) seja atingido pela organiza¬ 
ção, conforme mostra a Tabela 8.6. 



Níveis de Capacidade (Abordagem Contínua) 

Áreas de Processo por Nível 
de Maturidade (Abordagem 
por Estágios) 

NC 1 

(Executado) 

NC 2 

(Gerenciado) 

NC 3 
(Definido) 

APs NM 2 (Gerenciado) 

Perfil Alvo p/ NM 2 


APs NM 3 (Definido) 

Perfil Alvo p/ NM 3 



APs NM 4 (Quant. Gerenciado) 

Perfil Alvo p/ NM 4 

APs NM 5 (Otimizado) 

Perfil Alvo p/ NM 5 


Tabela 8.6 - Equivalência entre abordagens por estágios e contínua 
Adaptado de SEI (2010b) 
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Por exemplo, para que uma organização atinja o Nível de Maturidade 4 
(abordagem por estágios), todas as áreas de processo relativas aos níveis 2, 3 e 4 
de maturidade devem estar no Nível de Capacidade 3 (abordagem contínua). 


8 . 1.4 Aplicabilidade do modelo 

O CMMI pode ser implementado em quaisquer organizações cujo foco 
seja o desenvolvimento de produtos (sistemas em geral, software, hardware 
etc.) para o atendimento de necessidades de clientes externos ou internos, 
utilizando ou não recursos e/ou serviços terceirizados. 

A abordagem por estágios é mais recomendada para organizações que já 
estão familiarizadas com a incorporação de melhorias nos seus processos or¬ 
ganizacionais através de grandes saltos de qualidade, tais como aquelas que 
já possuem um nível de maturidade do CMM/CMMI ou que possuem mo¬ 
delos de qualidade baseados na melhoria simultânea e integrada de vários 
processos. 

A abordagem contínua é mais recomendada para organizações que pre¬ 
ferem uma evolução gradual na sua capacidade, processo a processo, possi¬ 
bilitando uma maior diluição do investimento a ser feito no programa de 
melhoria ao longo do tempo (organizações de menor porte também podem 
ter mais facilidade para utilizar o modelo nesta abordagem). Entretanto, serão 
requeridos maiores esforços para gerenciar a evolução segregada de cada prá¬ 
tica e as interdependências necessárias para viabilizar a equivalência com os 
níveis de maturidade da abordagem por estágios. 

A utilização de uma estratégia como o equivalent staging pode ser bastante 
rica para empresas que utilizam a abordagem contínua, mas que necessitem 
realizar benchmarkings em relação a outras organizações (para essa finalidade, 
os níveis de maturidade têm sido utilizados há muito tempo). 


8 . 1.5 Benefícios do modelo 

De acordo com resultados de desempenho relatados ao SEI em 2005 refe¬ 
rentes a mais de 25 organizações de grande porte, a implementação do CMMI 
trouxe benefícios quantificáveis bastante significativos ao longo do tempo, nas 
seguintes categorias (ver Tabela 8.7): 
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Categoria 

Média 

Alguns Exemplos 

Custo 

Redução de 20% 

• Redução de 20% nos custos de unidades de software. 

• Redução de 15% nos custos de remoção de defeitos. 

• Queda de 4,5% na taxa de overheaddos projetos. 

• Queda de 42% nos custos de retrabalho. 

• Melhoria e estabilização dos índices de desempenho de custos. 

Prazo 

Melhoria de 37% 

• Aumento do percentual de milestones atingidos com sucesso de 50% 
para aproximadamente 85%. 

• Redução do número médio de dias de atraso de aproximadamente 

50 para menos de 10. 

• Variação média do prazo realizado em relação ao previsto reduzida 
de cerca de 130 dias para menos de 20 dias. 

Produtividade 

Aumento de 62% 

• Aumento de 92% na quantidade de linhas de código por pessoa/dia. 

• Aumento de 100% no número de releases de software liberadas por 
ano. 

• Aumento de 50% na solução de requisições de mudança em relação 
ao plano. 

Qualidade 

Aumento de 50% 

• Atingimento da meta de 20 +/- 5 defeitos a cada 1000 linhas de 
código. 

• Apenas 2% dos defeitos encontrados no sistema em produção. 

• Redução de 7% na quantidade de requisições de mudança no 
ambiente de produção. 

Satisfação dos 
Clientes 

Aumento de 14% 

• Aumento de 55%, em comparação ao desempenho atingido pelo 
SW-CMM Nível 2. 

• Aumento de 10%, em comparação ao desempenho atingido pelo 
SW-CMM Nível 5. 

Retorno sobre 
o Investimento 

4,7:1 

• Retorno de 5:1 em relação às horas investidas em atividades de 
qualidade. 

• Retorno de 24:1 devido à sincronização da configuração de código 
entre localidades distintas (organização no Nível 5). 


Tabela 8.7 - Benefícios quantitativos da utilização do CMMI 
Fonte: página oficial do CMMI no site do SEI (www.sei.cmu.edu/cmmi/) 


Tomando como base a abordagem por estágios, podem também ser rela¬ 
cionados outros benefícios (alguns deles intangíveis) que a qualificação em 
cada nível de maturidade poderá trazer para uma organização: 

□ Nível 2 (Gerenciado) : 

A Maior grau de previsibilidade para os projetos. 

A Melhor controle dos acordos com fornecedores de produtos e 
serviços. 
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A Maior segurança na criação de uma base de medições operacio¬ 
nais, fundamentais para o acompanhamento e o gerenciamento 
dos projetos. 

□ Nível 3 (Definido) : 

A Maior robustez na execução dos processos e nos produtos, através 
do uso da integração do produto, verificação, validação e de téc¬ 
nicas de gestão de riscos. 

A Maior envolvimento da organização no estabelecimento de um 
ambiente orientado à integração das equipes. 

A Melhoria na comunicação interna e externa. 

A Maior acurácia nas tomadas de decisão, através do uso de méto¬ 
dos formais de análise e resolução. 

□ Nível 4 (Gerenciado Ouantitativamente) : 

A Maior precisão no gerenciamento dos projetos, através da utiliza¬ 
ção de indicadores de desempenho baseados em medições extraí¬ 
das desde o nível 2. 

□ Nível 5 (Otimizado) : 

A Tratamento adequado de todas as formas de inovações e mudan¬ 
ças possíveis, tanto nos processos quanto na tecnologia, e de seus 
reflexos no processo organizacional. 

A Maior acurácia no tratamento dos problemas, através da resolu¬ 
ção das causas comuns de variação. 

Através da utilização da abordagem contínua , uma quantidade maior de em¬ 
presas e organizações de menor porte poderá aderir ao modelo CMMI, de uma 
forma gradual e compatível com suas restrições operacionais e orçamentárias, con¬ 
tribuindo assim para a “universalização” dos conceitos e modelos de qualidade. 


8 . 1.6 Certificações relacionadas 

Não há, para o CMMI, o conceito de certificação individual ou empresa¬ 
rial. A qualificação de organizações nos níveis de maturidade é feita através de 
avaliações formais. 
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A implementação do CMMI nas organizações pode ser avaliada através de 
métodos desenvolvidos a partir de critérios de alto nível definidos pelo SEI 
(ARC) 79 . De acordo com esse documento, tais métodos agrupam-se em três 
classes, conforme as exigências em termos de grau de confiabilidade, custo, 
duração e necessidade de qualificação oficial. A Tabela 8.8 apresenta as prin¬ 
cipais características destas classes: 


Características 

Classe A 

Classe B 

Classe C 

Tipos de Evidências Objetivas 

Colhidas 

Documentos e 
entrevistas 

Documentos e 
entrevistas 

Documentos ou 
entrevistas 

Qualificação Formal 

Sim 

Não 

Não 

Cobertura de uma Unidade 
Organizacional 

Requerida 

Não requerida 

Não requerida 

Tamanho da Equipe 

No mínimo 4 

No mínimo 2 

No mínimo 1 

Requisitos para o Líder da Avaliação 

Avaliador Oficial 

Pessoa treinada e 
experiente 

Pessoa treinada e 
experiente 


Tabela 8.8 - Características principais das classes de avaliação 
Fonte: SEI (2011) 


□ Classe A : seguem todos os critérios do ARC, abrangendo todas as 
fontes de dados (entrevistas e análise de documentação), e são as úni¬ 
cas consideradas válidas para qualificação formal no Relatório de Per¬ 
fil de Maturidade 80 do SEI. 

□ Classe B : são subconjuntos da Classe A (também abrangendo duas 
fontes de dados) e não geram qualificação formal, sendo recomenda¬ 
das para avaliações iniciais ou avaliações de prontidão. 

□ Classe C : são subconjuntos da Classe B, podendo abranger uma das 
duas fontes de dados possíveis e também não geram qualificação for¬ 
mal, podendo ser utilizadas em autoavaliações periódicas conduzidas 
pelos grupos de suporte da organização. 

Um dos métodos de avaliação mais conhecidos e aplicados para qualifica¬ 
ção formal e benchmarking é o SCAMPI 81 A (Classe A), no qual os avaliadores 

79 ARC - Appmisal Requirements for CMMI. 

80 O Maturíty Profile Report é emitido duas vezes ao ano e contém os resultados estatísticos oficiais 
acerca das qualificações obtidas até o momento, considerando organizações em todo o mundo. 

81 SCAMPI - Standard CMMI Appraisal Method for Process Improvement. 
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observam, escutam e leem informações que são transformadas em anotações 
(podendo originar registros de desvios e/ou pontos fortes), que posteriormen¬ 
te integrarão os resultados finais. 

A preparação para uma avaliação SCAMPI envolve atividades tais como: 

□ Definição dos objetivos da avaliação (incluindo escopo/unidades or¬ 
ganizacionais a serem avaliadas e nível de maturidade a ser atingido). 

□ Planejamento da avaliação (incluindo estimativas de prazo, esforço e 
custo, definição do team leader e dos team members que comporão a 
banca da avaliação, cronograma de atividades, logística de acesso etc.). 

□ Treinamento da equipe de avaliação. 

□ Preparação das unidades organizacionais (incluindo coleta de evidên¬ 
cias objetivas da implementação das práticas). 

□ Revisão e análise das evidências coletadas. 

□ Avaliação de prontidão (para verificar se tanto a equipe de avaliação 
quanto as unidades organizacionais alvo estão aptas a passarem pela 
avaliação oficial). 

A cada três anos as organizações deverão ser novamente submetidas a uma 
avaliação oficial de mesmo nível ou superior, para que suas credenciais junto 
ao SEI sejam mantidas. 


8.2 MR-MPS-SW 

8 . 2.1 Histórico do modelo 

No início do século XXI, era usual para as empresas brasileiras de software 
a utilização da norma ISO 9000 como modelo de qualidade, em vez de mode¬ 
los específicos orientados a processos de software (tais como o CMM - Capa- 
bility Maturity Mo det). Além disso, os altos custos necessários para a obtenção 
de um nível de maturidade nesses modelos (considerando a avaliação por um 
SEI Partned 2 ) dificultavam a adoção desses modelos, principalmente pelas 
pequenas e médias empresas. 


82 Um SEI Partner é uma organização que tem profissionais credenciados pelo SEI para executar 
avaliações oficiais de maturidade. 
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O MPS.BR é um programa mobilizador, de longo prazo, criado em de¬ 
zembro de 2003, coordenado pela Associação para Promoção da Excelência 
do Software Brasileiro (SOFTEX) 83 , que conta com apoio do Ministério da 
Ciência, Tecnologia e Inovação (MCTI), da Financiadora de Estudos e Pro¬ 
jetos (FINEP), do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas 
(SEBRAE) e do Banco Interamericano de Desenvolvimento (BID/FUMIN). 

O objetivo do programa MPS.BR é a Melhoria de Processo de Software e 
Serviços, com duas metas a alcançar a médio e longo prazos: 

□ Meta técnica, visando a criação e o aprimoramento do Modelo MPS, 
com resultados esperados tais como: (i) guias do Modelo MPS; (ii) 
Instituições Implementadoras (II) credenciadas para prestar serviços 
de consultoria de implementação do Modelo de Referência MPS 
para Software (MR-MPS-SW) e/ou do Modelo de Referência MPS 
para Serviços (MR-MPS-SV); (iii) Instituições Avaliadoras (IA) cre¬ 
denciadas para prestar serviços de avaliação seguindo o método de 
avaliação (MA-MPS); (iv) Instituições de Consultoria de Aquisição 
(ICA) credenciadas para prestar serviços de consultoria de aquisição 
de software e/ou serviços relacionados. 

□ Meta de negócio, visando a disseminação e adoção do Modelo MPS, 
em todas as regiões do país, em um intervalo de tempo justo, a um 
custo razoável, tanto em micro, pequena e médias empresas (foco 
principal) quanto em grandes organizações privadas e governamen¬ 
tais, com resultados esperados tais como: (i) criação e aprimoramento 
do modelo de negócio MN-MPS; (ii) cursos, provas e workshops MPS; 
(iii) organizações que implementaram o Modelo MPS; (iv) organiza¬ 
ções com avaliação MPS publicada (prazo de validade de três anos). 

O período de 2004 a 2007 foi destinado ao projeto de implantação do 
programa MPS.BR, com os lançamentos das versões 1.0 (maio de 2005), 
1.1 (maio de 2006) e 1.2 (junho de 2007) do modelo MR-MPS, e os três 
anos seguintes (2008 a 2011) às atividades de consolidação. Em junho de 
2009 (com atualização em setembro), foi lançado o modelo de referência 


83 A SOFTEX é uma organização da sociedade civil de interesse público, cujo objetivo é aumentar 
a competitividade da indústria brasileira de software por meio de ações de capacitação, inovação, 
qualidade e atuação no mercado. 
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MR-MPS:2009, que implementou diversas melhorias, entre as quais a com¬ 
patibilidade com a norma internacional ISO 12207:2008 84 . 

Atualmente, o Guia Geral MPS de Software encontra-se na versão 2012, 
contemplando as seguintes modificações em relação à versão 2011: 

□ Alteração da nomenclatura de Guia Geral para Guia Geral MPS de 
Software. 

□ Alteração da nomenclatura de Modelo de Referência (MR-MPS) 
para Modelo de Referência MPS para Software (MR-MPS-SW). 

□ Alterações no Prefácio e na Introdução, incluindo o novo Modelo de 
Referência MPS para Serviços (MR-MPS-SV). 

□ Revisão e adequação das referências bibliográficas. 

8.2.2 Objetivos do modelo 

De acordo com SOFTEX (2012b), uma das metas do programa MPS. 
BR é definir e aprimorar um modelo de melhoria e avaliação de processo de 
software, visando preferencialmente às micro, pequenas e médias empresas, de 
forma a atender às suas necessidades de negócio e ser reconhecido nacional e 
internacionalmente como um modelo aplicável à indústria de software. O mo¬ 
delo MPS estabelece um modelo de processos de software e um processo e um 
método de avaliação de processos. Essa estrutura fornece sustentação e garante 
que o modelo MPS esteja sendo empregado de forma coerente com as suas 
definições. O modelo MPS estabelece também um modelo de negócio para 
apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software. 


8.2.3 Estrutura do modelo 

8.2.3.1 Visão geral do modelo 

O modelo MR-MPS-SW é formado pelos seguintes componentes: 

□ Guia Geral MPS de Software: contém a descrição geral do modelo 
MPS e detalha o Modelo de Referência MPS para Software (MR- 
-MPS-SW), seus componentes e as definições comuns necessárias 
para seu entendimento e aplicação. 


84 Norma específica acerca de processos do ciclo de vida do software. 
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□ Guia de Aquisição: descreve um processo de aquisição de software 
e serviços correlatos. É descrito como forma de apoiar as institui¬ 
ções que queiram adquirir produtos de software e serviços correlatos 
apoiando-se no MR-MPS-SW. 

□ Guia de Avaliação: descreve o processo e o método de avaliação MA- 
-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e 
instituições avaliadoras (IA). 

□ Guia de Implementação: série de documentos que fornecem orien¬ 
tações para implementar nas organizações os níveis de maturidade 
descritos no Modelo de Referência MR-MPS-SW. 

A base técnica para a definição do modelo MPS considerou: 

□ ISO/IEC 12207:2008. 

□ ISO/IEC 15504. 

□ ISO/IEC 20000. 

□ CMMI-DEV. 

□ CMMI-SVC. 

A Figura 8.4 mostra a estrutura na qual o Modelo de Referência (MR- 
-MPS-SW) está baseada. Os elementos dessa estrutura serão abordados nas 
seções a seguir. 



Figura 8.4 - Estrutura do MR-MPS, mostrando seus principais elementos 
Adaptado de SOFTEX (2012b) 
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8.2.3.2 Os níveis de maturidade 

Assim como acontece no CMMI, os níveis de maturidade do modelo MPS 
estabelecem patamares de evolução dos processos e representam estágios de 
melhoria para a implementação de processos em uma organização. 

A cada nível de maturidade está associado um conjunto de processos e um 
conjunto de atributos de processos cujo atendimento é necessário. Isso signifi¬ 
ca que, para alcançar um determinado nível de maturidade do MR-MPS-SW, 
os objetivos e resultados esperados dos processos devem ser atendidos e os 
resultados esperados dos atributos de processo estabelecidos para aquele nível 
também devem ser atendidos. 

O MR-MPS-SW possui sete níveis de maturidade, conforme mostra a Ta¬ 
bela 8.9: 


A 

Em Otimização 

B 

Gerenciado Quantitativamente 

C 

Definido 

D 

Largamente Definido 

E 

Parcialmente Definido 

F 

Gerenciado 

G 

Parcialmente Gerenciado 


Tabela 8.9 - Níveis de Maturidade do MR-MPS 
Fonte: SOFTEX (2012b) 


8.2.3.3 Os processos do MR-MPS-SW 

O MR-MPS-SW possui dezenove processos, distribuídos entre os níveis 
de maturidade. Isto significa que cada processo está associado ao primeiro 
nível de maturidade que tenha como requisito o atendimento a algum de seus 
atributos de processo. De acordo com SOFTEX (2012b), os processos são: 

□ Nível G - Parcialmente Gerenciado : o nível de maturidade G é com¬ 
posto pelos processos Gerência de Projetos e Gerência de Requisitos. 
Neste nível a implementação dos processos deve satisfazer os atribu- 
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tos de processo AP 1.1 e AP 2.1 (vide mais adiante sobre os atributos 
do processo). 

A Gerência de Projetos (GPR): o propósito é estabelecer e manter 
planos que definem atividades, recursos e responsabilidades do 
projeto, bem como prover informações sobre o andamento do 
projeto que permitam a realização de correções quando houver 
desvios significativos no desempenho do projeto. O propósito 
deste processo evolui à medida que a organização cresce em ma¬ 
turidade. Assim, a partir do nível E, alguns resultados evoluem 
e outros são incorporados, de forma que a gerência de projetos 
passe a ser realizada com base no processo definido para o projeto 
e nos planos integrados. No nível B, a gerência de projetos passa 
a ter um enfoque quantitativo, refletindo a alta maturidade que 
se espera da organização. Novamente, alguns resultados evoluem 
e outros são incorporados. 

A Gerência de Requisitos (GRE): o propósito é gerenciar os re¬ 
quisitos do produto e dos componentes do produto do projeto e 
identificar inconsistências entre os requisitos, os planos do proje¬ 
to e os produtos de trabalho do projeto. 

□ Nível F - Gerenciado : o nível de maturidade F é composto pelos 
processos do nível de maturidade anterior (G) acrescidos dos proces¬ 
sos Aquisição, Garantia da Qualidade, Gerência de Configuração, 
Gerência de Portfólio de Projetos e Medição. Neste nível a imple¬ 
mentação dos processos deve satisfazer os atributos de processo AP 
1.1, AP 2.1 e AP 2.2. 

A Aquisição (AQU): o propósito é gerenciar a aquisição de produ¬ 
tos 85 que satisfaçam as necessidades expressas pelo adquirente. 

A Gerência de Configuração (GCO): o propósito é estabelecer e 
manter a integridade de todos os produtos de trabalho de um 
processo ou projeto e disponibilizá-los a todos os envolvidos. 

A Gerência de Portfólio de Projetos (GPP): o propósito é iniciar 
e manter projetos que sejam necessários, suficientes e sustentá- 


85 No contexto do MR-MPS-SW considera-se que o termo produto pode incluir também serviços, 
desde que estes sejam entregues como parte do produto final ao cliente. 
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veis, de forma a atender aos objetivos estratégicos da organi¬ 
zação. Este processo compromete o investimento e os recursos 
organizacionais adequados e estabelece a autoridade necessária 
para executar os projetos selecionados. Ele executa a qualifica¬ 
ção contínua de projetos para confirmar que eles justificam a 
continuidade dos investimentos, ou podem ser redirecionados 
para justificar. 

A Garantia da Qualidade (GQA): o propósito é assegurar que os 
produtos de trabalho e a execução dos processos estejam em con¬ 
formidade com os planos, procedimentos e padrões estabelecidos. 
A Medição (MED): o propósito é coletar, armazenar, analisar e re¬ 
latar os dados relativos aos produtos desenvolvidos e aos processos 
implementados na organização e em seus projetos, de forma a 
apoiar os objetivos organizacionais. 

□ Nível E - Parcialmente Definido: o nível de maturidade E é com¬ 
posto pelos processos dos níveis de maturidade anteriores (G e F), 
acrescidos dos processos Avaliação e Melhoria do Processo Organi¬ 
zacional, Definição do Processo Organizacional, Gerência de Recur¬ 
sos Humanos e Gerência de Reutilização. O processo Gerência de 
Projetos sofre sua primeira evolução, retratando seu novo propósito: 
gerenciar o projeto com base no processo definido para o projeto e 
nos planos integrados. Neste nível a implementação dos processos 
deve satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2. 

A Avaliação e Melhoria do Processo Organizacional (AMP): o 

propósito é determinar o quanto os processos padrão da organiza¬ 
ção contribuem para alcançar os objetivos de negócio da organi¬ 
zação e para apoiar a organização a planejar, realizar e implantar 
melhorias contínuas nos processos com base no entendimento de 
seus pontos fortes e fracos. 

A Definição do Processo Organizacional (DFP): o propósito é 
estabelecer e manter um conjunto de ativos de processo organi¬ 
zacional e padrões do ambiente de trabalho usáveis e aplicáveis às 
necessidades de negócio da organização. 
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A Gerência de Recursos Humanos (GRH): o propósito é prover 
a organização e os projetos com os recursos humanos necessá¬ 
rios e manter suas competências adequadas às necessidades do 
negócio. 

A Gerência de Reutilização (GRU): o propósito é gerenciar o ciclo 
de vida dos ativos reutilizáveis. 

□ Nível D - Largamente Definido : o nível de maturidade D é com¬ 
posto pelos processos dos níveis de maturidade anteriores (G ao E), 
acrescidos dos processos Desenvolvimento de Requisitos, Integração 
do Produto, Projeto e Construção do Produto, Validação e Verifi¬ 
cação. Neste nível a implementação dos processos deve satisfazer os 
atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2. 

A Desenvolvimento de Requisitos (DRE): o propósito é defi¬ 
nir os requisitos do cliente, do produto e dos componentes do 
produto. 

A Integração do Produto (ITP): o propósito é compor os com¬ 
ponentes do produto, produzindo um produto integrado con¬ 
sistente com seu projeto, e demonstrar que os requisitos fun¬ 
cionais e não funcionais são satisfeitos para o ambiente alvo ou 
equivalente. 

A Projeto e Construção do Produto (PCP): o propósito é projetar, 
desenvolver e implementar soluções para atender aos requisitos. 

A Validação (VAL): o propósito é confirmar que um produto ou 
componente do produto atenderá a seu uso pretendido quando 
colocado no ambiente para o qual foi desenvolvido. 

A Verificação (VER): o propósito é confirmar que cada serviço e/ou 
produto de trabalho do processo ou do projeto atende apropria¬ 
damente aos requisitos especificados. 

□ Nível C - Definido : o nível de maturidade C é composto pelos pro¬ 
cessos dos níveis de maturidade anteriores (G ao D), acrescidos dos 
processos Desenvolvimento para Reutilização, Gerência de Decisões 
e Gerência de Riscos. Neste nível a implementação dos processos 
deve satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 
3.1 e AP 3.2. 
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A Desenvolvimento para Reutilização (DRU): o propósito é 
identificar oportunidades de reutilização sistemática de ativos na 
organização e, se possível, estabelecer um programa de reutiliza¬ 
ção para desenvolver ativos a partir de engenharia de domínios 
de aplicação. 

A Gerência de Decisões (GDE): o propósito é analisar possíveis 
decisões críticas usando um processo formal, com critérios estabe¬ 
lecidos, para avaliação das alternativas identificadas. 

A Gerência de Riscos (GRI): o propósito é identificar, analisar, tra¬ 
tar, monitorar e reduzir continuamente os riscos em nível organi¬ 
zacional e de projeto. 

□ Nível B - Gerenciado Quantitativamente : 

A Este nível de maturidade é composto pelos processos dos níveis 
de maturidade anteriores (G ao C). Neste nível o processo de Ge¬ 
rência de Projetos sofre sua segunda evolução, sendo acrescenta¬ 
dos novos resultados para atender aos objetivos de gerenciamento 
quantitativo. 

A Neste nível a implementação dos processos deve satisfazer os atri¬ 
butos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 e os 
RAPs 22 a 25 do AP 4.1. 

A A implementação dos processos selecionados para análise de de¬ 
sempenho deve satisfazer integralmente os atributos de processo 
AP 4.1 e AP 4.2. 

A Este nível não possui processos específicos. 

□ Nível A — Em Otimização: 

A Este nível de maturidade é composto pelos processos dos ní¬ 
veis de maturidade anteriores (G ao B). Neste nível a imple¬ 
mentação dos processos deve satisfazer os atributos de processo 
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2 e os RAPs 22 a 25 do 
AP 4.1. 

A A implementação dos processos selecionados para análise de de¬ 
sempenho deve satisfazer integralmente os atributos de processo 
AP 4.1 e AP 4.2. 
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A Os atributos de processo AP 5.1 e AP 5.2 devem ser integralmen¬ 
te satisfeitos pela implementação de pelo menos um dos processos 
selecionados para análise de desempenho. 

A Este nível não possui processos específicos. 


8.2.3.4 Os atributos de processos do MR-MPS-SW 

A capacidade de um processo, no MR-MPS-SW, reflete o grau de refina¬ 
mento e institucionalização com que este processo é executado na organiza¬ 
ção. Essa capacidade é representada por um conjunto de atributos de processo 
descritos em termos de resultados esperados. À medida que a organização evo¬ 
lui nos níveis de maturidade, um maior grau de capacidade deve ser atingido 
na execução do processo. 

Esses atributos são similares aos descritos no item 7.4.3.4 do Capítulo 7, 
quando descrevemos o MPS para serviços. 

Para atingir um nível de maturidade, é esperado que todos os proces¬ 
sos relativos a esse nível atendam aos resultados esperados dos próprios 
processos, assim como os resultados esperados dos atributos dos processos 
correspondentes àquele nível (e também aos processos de todos os níveis 
anteriores). 

Por exemplo: uma organização que atinge o nível F atende a todos os atri¬ 
butos de processo dos níveis G e F, para todos os processos correspondentes 
ao nível de maturidade F (que compreende também o nível G). Ao atingir o 
nível F, os processos do nível de maturidade G devem ser executados como 
um nível de capacidade. 

A Tabela 8.10 mostra, para cada nível de maturidade do MR-MPS-SW, 
os seus processos, os atributos de processo que precisam ser atingidos por 
cada processo, além de uma equivalência com os níveis de maturidade do 
CMMI-DEV. 
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Nível de 

Maturidade 

Processos do Nível de Maturidade 

Atributos de 

Processo 

Correspondentes 

Equivalência 
com o CMMI 

G - Parcialmente 
gerenciado 

• Gerência de requisitos (GRE) 

• Gerência de projetos (GPR) 

AP1.1 

AP2.1 

NÍVEL 2 

F - Gerenciado 

• Aquisição (AQU) 

• Gerência de Configuração (GCO) 

• Gerência de Portfólio de Projetos (GPP) 

• Garantia da Qualidade (GQA) 

• Medição (MED) 

AP1.1 

AP2.1 

AP2.2 

E - Parcialmente 
definido 

• Avaliação e Melhoria do Processo 
Organizacional (AMP) 

• Definição do Processo Organizacional (DFP) 

• Gerência de Recursos Humanos (GRH) 

• Gerência de Reutilização (GRU) 

• Gerência de Projetos (GRP) - evolução 

AP1.1 

AP2.1 

AP2.2 

AP3.1 

AP3.2 

NÍVEL 3 

D - Largamente 
definido 

• Desenvolvimento de Requisitos (DRE) 

• Integração do Produto (ITP) 

• Projeto e Construção do Produto (PCP) 

• Validação (VAL) 

• Verificação (VER) 

AP1.1 

AP2.1 

AP2.2 

AP3.1 

AP3.2 

C - Definido 

• Gerência de decisões (GDE) 

• Desenvolvimento para Reutilização (DRU) 

• Gerência de riscos (GRI) 

AP1.1 

AP2.1 

AP2.2 

AP3.1 

AP3.2 

B - Gerenciado 
quantitativamente 

• Gerência de Projetos (GPR) - evolução. 

• Não há processos específicos para este nível. 

AP1.1 

AP2.1 

AP2.2 

AP3.1 

AP3.2 

AP4.1 

AP4.2 

NÍVEL 4 

A-Em 
otimização 

• Não há processos específicos para este nível. 

AP1.1 

AP2.1 

AP2.2 

AP3.1 

AP3.2 

AP4.1 

AP4.2 

AP5.1 

AP5.2 

NÍVEL 5 


Tabela 8.10- Níveis de maturidade do MR-MPS-SW, seus atributos 
de processo correspondentes e sua relação com o CMMI-DEV 
Fonte: SOFTEX (2012b) 
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8 . 2.4 Aplicabilidade do modelo 

Assim como o CMMI, o MR-MPS-SW pode ser implementado em quais¬ 
quer organizações que tenham foco no desenvolvimento de software (sejam 
elas internas a uma empresa ou fornecedores externos), incluindo aquelas que 
possuem características de operação contínuas (tais como fábricas de software 
e fábricas de testes). 

A divisáo em sete níveis de maturidade permite que seja possível imple¬ 
mentar, avaliar e melhorar os processos (para o atendimento dos atributos de 
processos) em prazos mais curtos e de forma mais gradual. Este fato configura 
uma situaçáo bastante adequada para as micro, pequenas e médias empresas 
desenvolvedoras de software, devido aos menores custos de implementação 
e avaliação e à possibilidade de atingir resultados de melhoria de processos e 
maturidade em intervalos menores de tempo. 

A implementação de um modelo de maturidade nos moldes do MR-MPS- 
-SW pode ser um diferencial para tais organizações, diante das exigências cada 
vez maiores apresentadas pelos clientes em suas RFIs (Requests for Informa- 
tions) e RFPs (Request for Proposals) para contratação de produtos e serviços 
de software. 

Apesar do foco do modelo estar mais direcionado às pequenas e médias 
empresas, o modelo também é plenamente aplicável a organizações de maior 
tamanho, sejam elas públicas ou privadas. 

Este modelo tem sido bastante procurado pelas empresas brasileiras, a partir 
de programas de fomento à melhoria da qualidade de software promovidos 
pela SOFTEX. Em alguns casos, várias empresas se associam para contratar em 
conjunto serviços de consultoria especializada na implementação do modelo. 

Além das organizações que têm interesse em utilizar o MR-MPS-SW para 
a melhoria dos seus processos de software, outras empresas também fazem 
parte desse ecossistema, tendo participação atuante nos esforços de prepara¬ 
ção e avaliação: 

□ Instituições Implementadoras (II), credenciadas para prestar servi¬ 
ços de consultoria de implementação do modelo. 

□ Instituições Avaliadoras (IA), credenciadas para prestar serviços de 
avaliação segundo o método de avaliação MA-MPS. 
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8.2.5 Benefícios do modelo 

De acordo com resultados de desempenho relatados à SOFTEX em uma 
pesquisa realizada em 2012 com 1.326 empresas [veja SOFTEX (2013)], a 
adoção do modelo MPS teve um índice notório de mais de 62,2% totalmente 
satisfeitas com a adoção do modelo. A pesquisa ainda revela que as empresas 
que adotaram o modelo obtiveram como benefícios: 

□ A partir do nível E até o A as estimativas de prazo se tornam mais 
assertivas e consistentes. 

□ A partir do nível E até o A a produtividade e a qualidade também são 
maiores. 

Foi identificada também uma maior tendência para apresentar os bene¬ 
fícios esperados pela aplicação das técnicas da disciplina de Engenharia de 
Software (em termos de prazo, custo, produtividade e qualidade). 


8.2.6 Certificações relacionadas 

Neste modelo, as avaliações serão conduzidas por uma instituição creden¬ 
ciada para avaliação - IA (Instituição Avaliadora) -, e a implantação poderá 
ser realizada por uma instituição credenciada para implantação - II (Institui¬ 
ção Implementadora). 

O processo de avaliação do modelo MPS envolve atividades como: 

□ Contratar a avaliação (pesquisar instituições avaliadoras e estabelecer 
um contrato). 

□ Preparar a realização da avaliação (viabilizar, planejar e preparar a 
avaliação, conduzir a avaliação inicial, completar a preparação da 
avaliação). 

□ Realizar a avaliação final (conduzir a avaliação final e avaliar a execu¬ 
ção do processo de avaliação). 

□ Documentar os resultados da avaliação (relatar e registrar os resultados). 

A avaliação de maturidade do modelo MPS deve ser realizada por uma 
equipe composta por membros internos (representantes da unidade organi- 
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zacional) e membros externos (avaliador líder, avaliadores adjuntos da Insti¬ 
tuição Avaliadora e, opcionalmente, avaliadores em formação indicados pela 
SOFTEX). A duração da avaliação e a quantidade (mínima e máxima) de 
avaliadores são proporcionais à capacidade exigida para cada nível de maturi¬ 
dade. Uma avaliação pode durar de um a cinco dias e contar com uma equipe 
de três a nove avaliadores. 

A avaliação tem validade por dois anos. Ao final desses dois anos, a em¬ 
presa deverá passar por nova avaliação para manter a maturidade adquirida já 
avaliada ou evoluir o nível de maturidade. 


8.3 ISO/IEC 12207 

8.3.1 Visão geral do modelo 

A ISO/IEC 12207 é orientada para “Processos do Ciclo de Vida do 
Software”. O objetivo desta norma é criar um jramework que possibilite uma 
linguagem comum para a criação e o gerenciamento do software. 

A criação desta norma foi motivada justamente pelo fato de que existe 
uma miríade de padrões que criam dificuldades na engenharia e na gestão do 
software, notadamente na integração de produtos e serviços. 

A norma cobre o ciclo de vida do software, desde a sua concepção até o seu 
descarte, os processos para aquisição e suprimento de produtos de software e 
serviços, assim como os processos para controle e melhoria. 

Esta norma não é aplicada para certificação de processos em um esquema 
formal. Entretanto, pode ser imposta por associações de um país ou uma 
empresa como condição de realizar um negócio. Nesses casos, tais institui¬ 
ções devem especificar e tornar público o conjunto de processos, atividades 
e tarefas requeridas e que vão constituir a conformidade com este padrão 
internacional. 

A limitação desta norma é que ela não especifica como implementar ou 
desempenhar as atividades e tarefas incluídas nos processos. 

A Figura 8.5 apresenta o esquema da norma. 
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5. Processos 
Fundamentais 


5.1 Aquisição 


5.2 Fornecimento 



6. Processos de Apoio 


6.1 Documentação 


6.2 Gerência de Configuração 



6.3 Garantia da Qualidade 


6.4 Verificação 

6.5 Validação 

6.6 Revisão Conjunta 

6.7 Auditoria 


6.8 Resolução de Problema 


7. Processos Organizacionais 


7.1 Gerência 


7.2 Infraestrutura 



7.3 Melhoria 


7.4 Treinamento 


Figura 8.5 - Estrutura da ISO/IEC 12207 


rocessos Fundamentais 


□ O processo de Aquisição define as atividades do comprador (a orga¬ 
nização que adquire o sistema, produto de software ou serviço de sof¬ 
tware) e compreende as seguintes atividades: iniciação (definição da 
necessidade), preparação de request forproposal, preparação de contra¬ 
to, monitoramento do fornecedor e aceitação do produto ou serviço. 

□ O processo de Fornecimento define as atividades do fornecedor (a 
organização que fornece o sistema, produto de software ou serviço 
de software para o comprador) e compreende as seguintes atividades: ini¬ 
ciação (revisão dos requisitos), preparação de resposta, contratação, 
planejamento, execução e controle, revisão e avaliação e entrega. 
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□ O processo de Desenvolvimento define as atividades do desenvolve¬ 
dor (a organização que define e desenvolve o produto de software) 
e compreende as seguintes atividades: implementação do processo 
(seleção do ciclo de vida acordado), análise dos requisitos do sistema, 
projeto da arquitetura do sistema, análise dos requisitos do software, 
projeto da arquitetura do software, projeto detalhado do software, 
teste e codificação do software, integração do software, teste de qua¬ 
lificação do software, integração do sistema, teste de qualificação do 
sistema, instalação do software e suporte de aceitação do software. 

□ O processo de Operação define as atividades do operador (a organiza¬ 
ção que fornece o serviço de operação de um sistema computadorizado 
no ambiente real para seus usuários) e compreende as seguintes ativi¬ 
dades: implementação do processo (gestão de incidentes, problemas e 
mudança), teste operacional, operação do sistema e suporte ao usuário. 

□ O processo de Manutenção define atividades do mantenedor (a orga¬ 
nização que fornece o serviço de manutenção do produto de software, 
ou seja, gerenciamento das modificações do produto de software para 
mantê-lo atualizado e adequado para sua operação). Este processo 
compreende as seguintes atividades: implementação do processo (re¬ 
cebimento de solicitações e interface com gestão da configuração), 
análise de problemas e modificações, implementação da modificação, 
migração e desativação do software. 


Processos de Apoio 


□ O processo de Documentação define atividades para o registro da in¬ 
formação produzida pelos processos do ciclo de vida e compreende as 
seguintes atividades: implementação do processo (conteúdo e formato 
dos documentos), projeto e desenvolvimento, produção e manutenção. 

□ O processo de Gerência de Configuração define as seguintes ativida¬ 
des: implementação do processo (plano e procedimentos), identifi¬ 
cação da configuração, controle da configuração, status da configura¬ 
ção, avaliação da configuração, gestão das versões e da entrega. 

□ O processo de Garantia da Qualidade define as atividades para assegu¬ 
rar, objetivamente, que o produto de software e os processos estejam 
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em conformidade com os requisitos especificados e aderentes aos pla¬ 
nos estabelecidos 86 . Compreende as seguintes atividades: implementa¬ 
ção do processo, garantia do produto, garantia do processo e garantia 
da qualidade do sistema. 

□ O processo de Verificação define as atividades (para o comprador, o 
fornecedor ou uma terceira parte independente) de verificação dos 
produtos de software na profundidade requerida em função do proje¬ 
to de software. Compreende as seguintes atividades: implementação 
do processo e verificação (contrato, processo, requisitos, projeto, có¬ 
digo, integração e documentação). 

□ O processo de Validação define as atividades (para o comprador, o 
fornecedor ou uma terceira parte independente) de validação dos 
produtos dos projetos de software. Compreende as seguintes ativi¬ 
dades: implementação do processo e validação (testes de aceitação do 
software). 

□ O processo de Revisão Conjunta define as atividades para avaliar o 
status dos produtos de uma atividade. Este processo pode ser empre¬ 
gado por duas partes, onde uma revê o trabalho da outra em um fó¬ 
rum conjunto. Compreende as seguintes atividades: implementação 
do processo, revisões de gestão do projeto e revisões técnicas. 

□ O processo de Auditoria define atividades para determinar a con¬ 
formidade com os requisitos, planos e contratos. Compreende as se¬ 
guintes atividades: implementação do processo e auditoria. 

□ O processo de Resolução de Problema define um processo para ana¬ 
lisar e remover problemas, independentemente de sua natureza e ori¬ 
gem. Compreende as seguintes atividades: implementação do proces¬ 
so e resolução de problemas. 


cessos Organizacionais 


□ O processo de Gerência define as atividades básicas de gestão, incluin¬ 
do a gestão do projeto durante o processo de ciclo de vida. Compre- 


86 Revisões conjuntas, auditorias, verificação e validação podem ser usadas como técnicas de Garantia 
da Qualidade. 













336 Implantando a Governança de TI - 4 a edição 


ende as seguintes atividades: iniciação e definição do escopo, planeja¬ 
mento, execução e controle, revisão, avaliação e encerramento. 

□ O processo de Infraestrutura define as atividades básicas para o es¬ 
tabelecimento da estrutura de suporte de um processo de ciclo de 
vida. Compreende as seguintes atividades: implementação do pro¬ 
cesso, estabelecimento da infraestrutura (hardware, software, fer¬ 
ramentas, metodologias, padrões e instalações) e manutenção da 
infraestrutura. 

□ O processo de Melhoria define atividades para estabelecer, avaliar, 
medir, controlar e melhorar o processo de ciclo de vida. Compreen¬ 
de as seguintes atividades: estabelecimento do processo, avaliação do 
processo e melhoria do processo. 

□ O processo de Treinamento define atividades para prover e manter 
o pessoal treinado. Compreende as seguintes atividades: implemen¬ 
tação do processo, desenvolvimento de materiais de treinamento e 
implementação do plano de treinamento. 


8.3.2 Aplicabilidade do modelo 

Do nosso ponto de vista, este é um modelo bastante apropriado para a 
grande maioria das empresas, principalmente no tocante ao desenvolvimento 
de software, seja internamente ou por terceiros. Pode-se usar este modelo 
também em processos de outsourcing , definindo todos os padrões a serem 
utilizados e também os ciclos de vida. 

Como é um modelo aberto em termos do “como fazer”, pode ser integrado 
com outras iniciativas, tais como ISO 9001, PMBOK, CobiT e até mesmo 
o CMMI. 


8.4 ISO/IEC 9126 

8.4.1 Visão geral do modelo 

A ISO/IEC 9126 trata da avaliação do produto de software do ponto de 
vista das suas características de qualidade. A norma é aplicável para quem faz 
aquisição e/ou desenvolvimento de software, usuários, assim como para quem 
fornece suporte, manutenção ou realiza auditoria de software. 
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Assim como a ISO/IEC 12207, esta norma também não é aplicada com o 
objetivo de obter uma certificação através de um esquema de reconhecimento 
mútuo. A norma sugere sua aplicação nas seguintes situações: 

□ Definir os requisitos de qualidade do software. 

□ Avaliar especificações de software para verificar se satisfazem os requi¬ 
sitos de qualidade durante o desenvolvimento. 

□ Descrever características e atributos do software implementado. 

□ Avaliar o software desenvolvido antes de ser entregue. 

□ Avaliar o software antes da aceitação. 

A norma sugere a avaliação dos atributos da qualidade do software relacio¬ 
nados a Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manuteni- 
bilidade e Portabilidade. 


Funcionalidade: um conjunto de atributos que satisfazem necessidades 
implícitas e explícitas. 


Os subconjuntos de requisitos de qualidade funcionais são: 

□ Adequabilidade: atributo do software relacionado à presença e ade¬ 
quação de um conjunto de funções para tarefas específicas. 

□ Exatidão : atributos do software relacionados com a provisão do resul¬ 
tado ou efeito acordado e esperado. 

□ Interoperabilidade : atributo do software relacionado à sua habilidade 
para interagir com sistemas especificados. 

□ Compliance : atributos que fazem com que o software esteja aderente 
a padrões relacionados ou a convenções ou regulamentos em leis e 
prescrições similares. 

□ Segurança : atributos do software relacionados à sua habilidade para 
prevenir acessos não autorizados (sejam acidentais ou deliberados) a 
programas e dados. 


Confiabilidade: um conjunto de atributos relacionados à capacidade do 
software de manter seu nível de desempenho, conforme as condições 
estabelecidas por um período de tempo estabelecido. 
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Subconjuntos de requisitos de qualidade de confiabilidade são: 

□ Maturidade : atributos do software relacionados à frequência de falhas 
por defeito no software. 

□ Tolerância a falhas : atributos do software relacionados com sua habi¬ 
lidade para manter um nível de desempenho especificado em casos de 
falhas do software ou mau funcionamento de interfaces especificadas. 

□ Capacidade de recuperação : atributos do software relacionados com 
a sua capacidade de restabelecer seu nível de desempenho e recuperar 
os dados diretamente afetados em caso de falhas, assim como com o 
tempo e esforços necessários para sua recuperação. 


Usabilidade: um conjunto de atributos relacionados ao esforço para usar 
o software ou na avaliação individual de tal uso, por um ou mais usuários. 


Subconjuntos de requisitos de qualidade de usabilidade são: 

□ Facilidade de entendimento : atributos do software relacionados 
ao esforço do usuário para reconhecer o conceito lógico e sua 
aplicação. 

□ Facilidade de aprendizagem : atributos do software relacionados ao 
esforço do usuário aprender sua aplicação. 

□ Facilidade de operação : atributos do software relacionados ao esforço 
do usuário para operar e controlar a operação do software. 


Eficiência: um conjunto de atributos que dizem respeito à relação entre 
o nível de desempenho do software e a quantidade de recursos usada, 
sob condições estabelecidas. 


Subconjuntos de requisitos de qualidade de eficiência são: 

□ Comportamento do tempo : atributos do software relacionados com 
os tempos de processamento e resposta, assim como as taxas de 
throughput no desempenho de suas funções. 














Modelos para Processos de Software 339 


□ Comportamento de recursos : atributos do software relacionados com 
a quantidade de recursos usados e a duração da sua utilização no de¬ 
sempenho de suas funções. 


Manutenibilidade: um conjunto de atributos relacionados ao esforço 
necessário para realizar modificações especificadas. 


Subconjuntos de requisitos de qualidade de manutenibilidade são: 

□ Facilidade de análise : atributos de software relacionados ao esforço 
necessário para diagnosticar deficiências ou causas de falhas ou para 
identificar partes a serem modificadas. 

□ Facilidade de mudança : atributos do software relacionados ao esforço 
necessário para a modificação, remoção de falhas ou para mudanças 
de ambiente. 

□ Estabilidade : atributos do software relacionados ao risco de efeitos 
inesperados de modificações. 

□ Facilidade de teste : atributos do software relacionados ao esforço ne¬ 
cessário para validar o software modificado. 


Portabilidade: um conjunto de atributos de software relacionados à ha¬ 
bilidade do software ser transferido de um ambiente para outro. 


Subconjuntos de requisitos de qualidade de portabilidade são: 

□ Capacidade de adaptação : atributos do software relacionados à opor¬ 
tunidade para a sua adaptação a diferentes ambientes sem a aplicação 
de outras ações ou meios do que aqueles providos para o propósito 
do software considerado. 

□ Facilidade de instalação : atributos do software relacionados ao esfor¬ 
ço necessário para instalar o software no ambiente especificado. 

□ Nível de conformidade : atributos que fazem o software ser aderente a 
padrões ou convenções relacionados à portabilidade. 
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□ Facilidade de substituição : atributos relacionados à oportunidade do 
software substituir outro software no mesmo ambiente. 


8.4.2 Aplicabilidade do modelo 

Esta norma pode ser aplicada para avaliação e aceitação de softwares- 
produtos ou softwares desenvolvidos ou adquiridos pela empresa, conforme 
os requisitos estabelecidos para cada uma das características da qualidade es¬ 
peradas para o software. Da mesma forma, esta norma pode auxiliar na espe¬ 
cificação de condições do teste de aceitação ou do processo de validação de 
softwares que a empresa adquire. 


8.5 IBM RUP - UMA BREVE VISÃO 

O RUP (Rational Unified Process ) é um framework passível de adaptação, 
orientado principalmente para o desenvolvimento de projetos de software. 
De acordo com Kruchten (2000), é um processo de engenharia de software, 
um processo de produto e também um framework de processo. Ainda confor¬ 
me este autor, o RUP captura elementos das melhores práticas do desenvolvi¬ 
mento moderno do software e baseia-se nos seguintes fundamentos: 

□ Desenvolvimento iterativo do software. 

□ Gestão de requisitos. 

□ Uso de arquiteturas baseadas em componentes. 

□ Modelagem visual do software. 

□ Verificação contínua da qualidade do software. 

□ Controle de mudanças no software. 

O RUP foi desenvolvido pela Rational , que foi adquirida pela IBM (atual¬ 
mente é um produto IBM). Combina um ciclo de vida de desenvolvimento 
de software baseado no modelo espiral, juntamente com processos para a ges¬ 
tão do projeto. A Figura 8.6 apresenta brevemente o modelo do RUP. 
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Figura 8.6 - Modelo RUP 
Adaptado de Kruchten (2000) 


O ciclo de vida é composto por quatro fases: Concepção, Elaboração, 
Construção e Transição. 

A fase de Concepção consiste em estabelecer o escopo do projeto, os cri¬ 
térios de aceitação e o que não fará parte do produto, em definir os cenários 
de comportamento do produto, definir a arquitetura para atender ao cenário, 
estimar os custos e prazos para o projeto como um todo e estimar riscos. 

A fase de Elaboração consiste em analisar o domínio do problema, estabe¬ 
lecer a arquitetura do produto, desenvolver o plano do projeto e eliminar os 
elementos de alto risco do projeto, assim como demonstrar que a arquitetura 
apoiará a visão do produto dentro do custo e do prazo estimados. 

A fase de Construção consiste no desenvolvimento das funcionalidades, na 
integração de componentes ao produto e na finalização de versões operacio¬ 
nais do produto. 
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A fase de Transição consiste em mover o produto de software para a comu¬ 
nidade de usuários. 

A RUP, como jramework , emprega, para o desenvolvimento de seus ar¬ 
tefatos, a linguagem de modelagem Unijied Modeling Language (UML). Os 
principais artefatos do RUP são: 

□ Solicitações dos interessados (stakeholders requests). 

□ Visão ( vision ). 

□ Business Case. 

□ Lista de riscos ( risk list). 

□ Glossário (glossary ). 

□ Especificação suplementar ( supplementary specification ). 

□ Modelo de caso de uso (case use model). 

□ Plano de desenvolvimento do software ( software developmentplan ). 

□ Documento da arquitetura do software ( software architecture 
document). 

□ Plano de teste ( testplan ). 

□ Modelo de análise ( analysis model). 

□ Modelo de projeto (design model). 

□ Plano de implantação (deploymentplan). 

□ Modelo de implementação (implementation model). 

O RUP traz em seu jramework o conceito de iterações, que são evoluções 
do produto à medida que se avança no ciclo de vida, ou seja, trabalha com 
versões intermediárias até se chegar à versão definitiva. Com isso, de acordo 
com o que preconiza, a RUP consegue reduzir riscos e acomodar mudanças 
nos requisitos ao longo do projeto. 

Os workjlows da RUP organizam os elementos dos processos (pessoas, ati¬ 
vidades e artefatos) em uma sequência de atividades que produzem resultados 
que agregam valor e que mostram as interações entre as pessoas. 

O RUP consiste em nove workjlows básicos, sendo seis de engenharia 
e três de suporte. Os de engenharia são: modelagem de negócio, requisi¬ 
tos, análise e projeto, implementação, teste e entrega (deployment). Os de 
suporte são: gestão de projetos, gestão da mudança e da configuração e 
ambiente. 
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8.6 MSF - UMA BREVE VISÃO 

O MSF (. Microsoft Solutions Frameivork ) é a solução da Microsoft para os 
seguintes tipos de projetos (vide www.microsoft.com/msf): 

□ Desenvolvimento de software. 

□ Implantação de software (sistemas operacionais, software de gestão 
da configuração etc.). 

□ Implantação de pacotes como Sistemas Integrados de Gestão etc. 

□ Qualquer combinação dos itens citados. 

De acordo com a Microsoft, o MSF é um framework que pode ser adapta¬ 
do pelo usuário em função de suas necessidades particulares. 

Os principais componentes do modelo são: 

□ Princípios fundamentais do modelo. 

□ Modelos de equipe e de processo. 

□ Disciplinas do modelo. 

Os princípios fundamentais consistem em: promover a comunicação aber¬ 
ta, dar autonomia para a equipe, trabalhar em direção ao compartilhamento 
da visão, estabelecer claramente as responsabilidades, focar a entrega de valor 
para o negócio, manter-se ágil e esperar mudanças, investir em qualidade e 
aprender com todas as experiências. 

O modelo de equipe determina alguns papéis, habilidades e conhecimen¬ 
tos para o sucesso de projetos de tecnologia da informação. Os papéis são 
os relativos a: gestão do programa, desenvolvimento, teste, gestão da release , 
experiência do usuário e do gerente do produto. 

O modelo de processos consiste no ciclo de vida de desenvolvimento do proje¬ 
to propriamente e comporta as seguintes grandes fases: desenvolvimento da visão, 
planejamento, desenvolvimento, estabilização e implantação. De acordo com a 
Microsoft, este modelo é uma combinação dos ciclos de vida cascata e espiral. 

As disciplinas do modelo são: gerência de projetos (que se baseia no 
PMBOK e no PRINCE2), gerenciamento de risco e gestão da prontidão, que 
diz respeito à definição, avaliação, mudança e evolução das habilidades das 
equipes do projeto ao longo do ciclo de vida do projeto. 
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Entre as disciplinas mais relevantes no contexto da Governança de TI, está o 
gerenciamento das iniciativas de implementação de novos elementos ou de ele¬ 
mentos modificados no contexto da TI. Tais iniciativas se materializam em pro¬ 
jetos, que, por sua vez, podem ser organizados em programas e/ou portfólios. 

Neste capítulo apresentamos alguns dos modelos mais conhecidos para 
essa disciplina: os modelos do PMI (Project Management Institutê) para Ge¬ 
renciamento de Projetos (PMBOK), Gerenciamento de Programas e Geren¬ 
ciamento de Portfólio, a metodologia europeia PRINCE 2 e o método para 
desenvolvimento ágil Scrum. 

9.1 PMBOK 

9.1.1 Histórico do modelo 

O PMBOK {ProjectManagement Body ofKnowledge ) foi desenvolvido con¬ 
tando com a colaboração de várias dezenas de profissionais afiliados ao PMI 
e de origens diversas. A primeira versáo do PMBOK foi publicada em 1996, 
a segunda versáo em 2000, a terceira versáo em 2004, a quarta em 2008 e a 
quinta ediçáo em 2013. 


9.1.2 Objetivos do modelo 

De acordo com PMI (2013a), o principal objetivo do Guia PMBOK é 
identificar o subconjunto do corpo de conhecimentos em gerenciamento de 
projetos que é amplamente reconhecido como boa prática. 
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Ainda conforme o PMI: 

□ Fornece e promove um vocabulário comum para a profissão de geren¬ 
ciamento de projetos. 

□ Vê o padrão como uma referência base para o desenvolvimento e a 
certificação profissional. 

□ Não é um modelo completo. 

□ Não é uma metodologia. 

□ É um guia para os processos de gerenciamento de projetos, ferramen¬ 
tas e técnicas. 

Para o PMI, um projeto é: “um empreendimento temporário desenvolvido 
para criar um produto, serviço ou resultado único. A natureza temporária dos 
projetos indica que ele tem um início e um fim bem definidos. O fim é alcan¬ 
çado quando os objetivos do projeto foram atendidos ou quando o projeto 
é finalizado porque seus objetivos não podem ser alcançados, ou quando a 
necessidade do projeto não existe mais”. 

A gerência do projeto, por sua vez, é: “a aplicação de conhecimento, ha¬ 
bilidades, ferramentas e técnicas às atividades do projeto para atender aos 
requisitos do projeto”. 

Gerenciar um projeto envolve ainda os seguintes aspectos: 

□ Identificação de requisitos. 

□ Atendimento de várias necessidades, questões e expectativas dos 
stakeholders no planejamento e na execução do projeto. 

□ Estabelecimento, manutenção e execução de comunicação entre os 
stakeholders ativos no projeto. 

□ Gerenciamento dos stakeholders em direção aos requisitos do projeto 
e criação dos entregáveis do projeto. 

□ Balancear as restrições que competem no projeto, tais como es¬ 
copo, qualidade, cronograma, orçamento, recursos, riscos, dentre 


outros. 
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9.1.3 Estrutura do modelo 

O que mudou em relação à quarta edição: 

□ Foram estabelecidas regras para dar maior consistência no tratamento 
da ordem e detalhes de informação sobre entradas, ferramentas, téc¬ 
nicas e saídas. 

□ Foram estabelecidas regras para assegurar a harmonização do glossá¬ 
rio de termos com o glossário de termos de gestão de projetos (deno¬ 
minado PMI Lexicon ofProject Management Terms). 

□ Para melhorar a consistência acerca dos planos subsidiários que fazem 
o plano de gerenciamento do projeto, foram incluídos mais quatro 
processos de planejamento: Gerenciamento do plano de escopo, Ge¬ 
renciamento do plano do cronograma, Gerenciamento do plano de 
custo e Gerenciamento do plano dos stakeholders. 

□ Para melhorar a consistência em relação aos dados do projeto e fluxos 
de informação, foram redefinidos: dados de desempenho do traba¬ 
lho, informações de desempenho do trabalho e relatórios de desem¬ 
penho do trabalho. 

□ As seções 1.2, 1.4 e 1.6 da Introdução foram alteradas para maior har¬ 
monização com os conceitos dos padrões de programa e de portfólio. 

□ Na seção 2 (Ciclo de vida do projeto e organização), as subseções 
sobre influência organizacional na gestão do projeto e sobre stake¬ 
holders foram expandidas e foi criada uma seção sobre características 
e estruturas de equipes de projetos. 

□ A seção 10, que trata da comunicação do projeto, foi separada em 
duas seções. 

□ Vários nomes de processos foram alterados, tais como: Planejamento 
da qualidade virou Planejamento da gestão da qualidade; Monitora¬ 
ção e controle de riscos virou Controle de riscos; Plano de aquisição 
virou Plano de gerenciamento da aquisição etc. 

□ Definições de processos foram alteradas para: Desenvolvimento do 
Project Charter , Desenvolvimento do plano de gerenciamento do pro¬ 
jeto, Dirigir e gerenciar o trabalho do projeto, Monitorar e controlar 
o trabalho do projeto e Executar o controle integrado do projeto. 

□ Foram revistos os fluxos de informação, removendo inconsistências. 
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9.1.3.1 Áreas de conhecimento do gerenciamento de projetos 

O modelo está estruturado em dez áreas de conhecimento em gerencia¬ 
mento de projetos, conforme mostra a Figura 9.1. 


ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS 


GERENCIAMENTO DA INTEGRAÇÃO DO PROJETO 

GERENCIAMENTO DO ESCOPO DO PROJETO 

GERENCIAMENTO DO TEMPO DO PROJETO 

4.1 Desenvolver o termo de abertura do projeto 

4.2 Desenvolver o plano de gerenciamento do projeto 

4.3 Dirigir e gerenciar o trabalho do projeto 

4.4 Monitorar e controlar o trabalho do projeto 

4.5 Realizar o controle integrado de mudanças 

4.6 Encerrar o projeto ou fase 


5.1 Planejar o gerenciamento do escopo 

5.2 Coletar os requisitos 

5.2 Definir o escopo 

5.3 Criar a EAP 

5.4 Validar o escopo 

5.5 Controlar o escopo 

6.1 Planejar o gerenciamento do cronograma 

6.2 Definir as atividades 

6.3 Sequenciar as atividades 

6.4 Estimar os recursos das atividades 

6.5 Estimar as durações das atividades 

6.6 Desenvolver o cronograma 

6.7 Controlar o cronograma 


GERENCIAMENTO DOS CUSTOS DO PROJETO GERENCIAMENTO DA QUALIDADE DO PROJETO GERENCIAMENTO DOS RECURSOS HUMANOS DO PROJETO 


8.1 Planejar o gerenciamento da qualidade 

8.2 Realizar a garantia da qualidade 

8.3 Controlar a qualidade 


7.1 Planejar o gerenciamento dos custos do projeto 

7.2 Estimar os custos 

7.3 Determinar o orçamento 

7.4 Controlar os custos 


9.1 Planejar o gerenciamento de recursos humanos 

9.2 Adquirir a equipe do projeto 

9.3 Desenvolver a equipe do projeto 

9.4 Gerenciar a equipe do projeto 


GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO 


10.1 Planejar o gerenciamento das comunicações 

10.2 Gerenciar as comunicações 

10.3 Controlar as comunicações 


GERENCIAMENTO DOS RISCOS DO PROJETO 


11.1 Planejar o gerenciamento dos riscos 

11.2 Identificar os riscos 

11.3 Realizar a análise qualitativa dos riscos 

11.4 Realizar a análise quantitativa dos riscos 

11.5 Planejar as respostas aos riscos 

11.6 Controlar os riscos 


GERENCIAMENTO DAS AQUISIÇÕES DO PROJETO 


12.1 Planejar o gerenciamento das aquisições 

12.2 Conduzir as aquisições 

12.3 Controlar as aquisições 

12.4 Encerrar as aquisições 


GERENCIAMENTO DOS STAKEHOLDERS DO PROJETO 


13.1 Identificar os stakeholders 

13.2 Planejar o gerenciamento dos stakeholders 

13.3 Gerenciar o engajamento dos stakeholders 

13.4 Controlar o engajamento dos stakeholders 


Figura 9.1 - Áreas de conhecimento do PMBOK 
Adaptado de PMI (2013a) 


Os processos de gerenciamento de projetos, representados pelas dez áreas 
de conhecimento, sáo agrupados, de acordo com o modelo, em: 

□ Grupo de processos de iniciação : define um novo projeto ou uma 
nova fase do projeto pela obtençáo da autorização para iniciar o pro¬ 
jeto ou a fase. 
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□ Grupo de processos de planejamento : estabelece o escopo total do es¬ 
forço, define e refina objetivos e desenvolve o curso de ação requerido 
para obter esses objetivos. 

□ Grupo de processos de execução : completa o trabalho definido no 
plano de gerenciamento do projeto que satisfaz as especificações do 
projeto. 

□ Grupo de processos de monitoramento e controle : acompanha, anali¬ 
sa e controla o progresso do desempenho do projeto; identifica quais¬ 
quer áreas nas quais mudanças no plano são requeridas e inicia as 
mudanças correspondentes. 

□ Grupo de processos de encerramento : finaliza todas as atividades por 
todos os grupos de processo de gerenciamento, visando encerrar for¬ 
malmente o projeto ou fase. 

A Tabela 9.1 apresenta o relacionamento entre as áreas de conhecimento e 
os grupos de processo de gerenciamento de projetos. 


Áreas de 
Conhecimento 

Grupos de Processos de Gerenciamento de Projetos 

Iniciação 

Planejamento 

Execução 

Monitoramento 
e Controle 

Encerramento 

4. Gerenciamento 
da integração do 
projeto 

4.1. Desenvolver 
o termo de 
abertura do 
projeto 

4.2. Desenvolver 
o plano de 
gerenciamento 
do projeto 

4.3. Dirigir e 
gerenciar o 
trabalho do 
projeto 

4.4. Monitorar 
e controlar o 
trabalho do 
projeto 

4.5. Realizar 
o controle 
integrado do 
projeto 

4.6. Encerrar 
o projeto ou 
fase 

5. Gerenciamento 
do escopo do 
projeto 


5.1. Planejar o 
gerenciamento 
do escopo 

5.2. Coletar 
requisitos 

5.3. Definir 
escopo 

5.4. Criar a EAP 


5.5. Validar o 
escopo 

5.6. Controlar o 
escopo 
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Áreas de 
Conhecimento 

Grupos de Processos de Gerenciamento de Projetos 

Iniciação 

Planejamento 

Execução 

Monitoramento 
e Controle 

Encerramento 

6. Gerenciamento 
do tempo do 
projeto 


6.1. Planejar o 
gerenciamento 
do cronograma 

6.2. Definir 
atividades 

6.3. Sequenciar 
atividades 

6.4. Estimar os 
recursos das 
atividades 

6.5. Estimar a 
duração das 
atividades 

6.6. Desenvolver 
o cronograma 


6.7. Controlar o 
cronograma 


7. Gerenciamento 
dos custos do 
projeto 


7.1. Planejar o 
gerenciamento do 
custo 

7.2. Estimar os 
custos 

7.3. Determinar o 
orçamento 


7.4. Controlar os 
custos 


8. Gerenciamento 
da qualidade do 
projeto 


8.1. Planejar o 
gerenciamento da 
qualidade 

8.2. Realizar 
a garantia da 
qualidade 

8.3. Controlar a 
qualidade 


9. Gerenciamento 
dos recursos 
humanos do 
projeto 


9.1. Planejar o 
gerenciamento 
dos recursos 
humanos 

9.2. Mobilizar 
a equipe do 
projeto 

9.3. Desenvolver 
a equipe do 
projeto 

9.4. Gerenciar 
a equipe do 
projeto 



10. Gerenciamento 
das comunicações 
do projeto 


10.1. Planejar o 

gerenciamento 

das 

comunicações 

10.2. 

Gerenciar as 
comunicações 

10.3. Controlar 
comunicações 
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Áreas de 
Conhecimento 

Grupos de Processos de Gerenciamento de Projetos 

Iniciação 

Planejamento 

Execução 

Monitoramento 
e Controle 

Encerramento 

11. Gerenciamento 
dos riscos do 
projeto 


11.1. Planejar o 
gerenciamento 
dos riscos 

11.2. Identificar os 
riscos 

11.3. Realizara 
análise qualitativa 
dos riscos 

11.4. Realizar 
a análise 
quantitativa dos 
riscos 

11.5. Planejar 
a resposta aos 
riscos 


11.6. 

Monitorar e 
controlar os 
riscos 


12. Gerenciamento 
das aquisições do 
projeto 


12.1. Planejar o 
gerenciamento 
das aquisições 

12.2. Conduzir 
as aquisições 

12.3. Controlar 
as aquisições 

12.4. Encerrar 
as aquisições 

13. Gerenciamento 
dos stakeholders 
do projeto 

13.1. Identificar 
os stakeholders 

13.2. Planejar o 
gerenciamento 
dos stakeholders 

13.3. Gerenciar 
o engajamento 
dos 

stakeholders 

13.4. Controlar 
o engajamento 
dos 

stakeholders 



Tabela 9.1 - Processos de gerenciamento de projetos e áreas de conhecimento 
Adaptado de PMI (2013a) 


9.1.3.2 - Processos de gerenciamento de projetos 

A Figura 9.2 mostra as interações entre os grupos de processos de geren¬ 
ciamento de projetos. 
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Figura 9.2 - Interações dos processos de gerenciamento de projetos 
Adaptado de PMI (2013a) 


9.1.3.2.1 Grupo de processos de iniciação 

Este grupo é formado pelos processos responsáveis pela autorização formal 
para iniciar um novo projeto ou uma fase do projeto. Os processos que fazem 
parte deste grupo são: 

□ Desenvolver o termo de abertura do projeto : desenvolve um docu¬ 
mento que autoriza, formalmente, a existência de um projeto e for¬ 
nece autoridade para o gerente de projeto aplicar recursos organiza¬ 
cionais às atividades do projeto. 

□ Identificar as partes interessadas : identifica pessoas, grupos ou orga¬ 
nizações que podem impactar ou ser impactados por uma decisão, 
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atividade ou resultado do projeto; analisa e documenta informações 
relevantes relativas aos seus interesses, nível de engajamento, interde¬ 
pendências, influência e seu impacto potencial no êxito do projeto. 


9.1.3.2.2 Grupo de processos de planejamento 

Os processos de planejamento têm por objetivo estabelecer o escopo total 
do esforço, definir e refinar os objetivos e desenvolver o curso de ação neces¬ 
sário para alcançar esses objetivos. 

□ Desenvolver o plano de gerenciamento do projeto : documenta as 
ações necessárias para definir, preparar, integrar e coordenar todos 
os planos auxiliares. O plano de gerenciamento do projeto torna-se 
a fonte primária de informação sobre como o projeto será planejado, 
executado, monitorado e controlado e encerrado. As linhas de base 87 
e os planos subsidiários integrados do projeto podem ser incluídos no 
plano de gerenciamento do projeto. 

□ Planejar o gerenciamento do escopo : cria um plano de gerenciamento 
do escopo do projeto que documenta como ele será definido, valida¬ 
do e controlado. 

□ Coletar os requisitos : define e documenta as necessidades das partes 
interessadas a fim de atender aos objetivos do projeto. 

□ Definir o escopo : desenvolve uma descrição detalhada do projeto e 
do produto. 

□ Criar a EAP : realiza a subdivisão das principais entregas do projeto e 
do trabalho do projeto em componentes menores e mais facilmente 
gerenciáveis. 

□ Planejar o gerenciamento do cronograma : estabelece as políticas, os 
procedimentos e a documentação para o planejamento, desenvol¬ 
vimento, gerenciamento, execução e o controle do cronograma do 
projeto. 

□ Definir as atividades : identifica e documenta as ações específicas a 
serem desempenhadas para produzir as entregas do projeto. 


87 Linha de base é a versão final do plano aprovado, a partir da qual se faz o controle do progresso do 
projeto, e contra a qual é comparada a situação atual. 
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□ Sequenciar as atividades : identifica e documenta os relacionamentos 
entre as atividades do projeto. 

□ Estimar os recursos da atividade : realiza estimativa sobre os tipos e as 
quantidades de materiais, pessoal, equipamentos ou fornecimentos 
requeridos para desempenhar cada atividade. 

□ Estimar a duração das atividades : realiza estimativa do número de 
períodos de trabalho que serão necessários para completar atividades 
específicas com os recursos estimados. 

□ Desenvolver o cronograma : analisa as sequências das atividades, suas 
durações, recursos necessários e restrições, visando criar o cronogra¬ 
ma do projeto. 

□ Planejar o gerenciamento do custo : estabelece as políticas, os procedi¬ 
mentos e a documentação para o planejamento, a gestão, as despesas, 
e o controle dos custos do projeto. 

□ Estimar os custos : desenvolve uma estimativa dos recursos monetá¬ 
rios necessários para executar as atividades do projeto. 

□ Determinar o orçamento : agrega os custos estimados das atividades 
individuais ou pacotes de trabalho para estabelecer uma linha de base 
dos custos autorizada. 

□ Planejar o gerenciamento da qualidade : identifica os requisitos e/ou 
padrões de qualidade do projeto e do produto, além de documentar 
como o projeto atingirá a conformidade. 

□ Planejar o gerenciamento dos recursos humanos : identifica e documen¬ 
ta papéis, responsabilidades, habilidades necessárias e relações hierárqui¬ 
cas do projeto, além de criar um plano de gerenciamento de pessoal. 

□ Planejar o gerenciamento das comunicações : desenvolve uma abor¬ 
dagem apropriada e um plano de comunicações do projeto com base 
nas necessidades de informação e requisitos das partes interessadas, e 
nos ativos organizacionais disponíveis. 

□ Planejar o gerenciamento de riscos : define como conduzir as ativida¬ 
des de gerenciamento dos riscos de um projeto. 

□ Identificar os riscos : determina os riscos que podem afetar o projeto e 
documenta suas características. 

□ Realizar a análise qualitativa de riscos : prioriza os riscos para análise 
ou ação adicional através da avaliação e combinação de sua probabi¬ 
lidade de ocorrência e impacto. 
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□ Realizar análise quantitativa de risco : analisa numericamente o efeito 
dos riscos identificados nos objetivos gerais do projeto. 

□ Planejar as respostas a riscos : desenvolve opções e ações para aumen¬ 
tar as oportunidades e reduzir as ameaças aos objetivos do projeto. 

□ Planejar as aquisições : documenta as decisões de compras do pro¬ 
jeto, especificando a abordagem e identificando fornecedores em 
potencial. 

□ Planejar o gerenciamento das partes interessadas : desenvolve estraté¬ 
gias apropriadas de gerenciamento para engajar as partes interessadas 
de maneira eficaz no decorrer de todo o ciclo de vida do projeto, com 
base na análise das suas necessidades, interesses e impacto potencial 
no sucesso do projeto. 

9.1.3.2.3 Grupo de processos de execução 

Contém os processos executados para completar o trabalho definido 
no plano de gerenciamento do projeto que satisfaz as especificações do 
projeto. 

□ Dirigir e gerenciar o trabalho do projeto : lidera e realiza o trabalho 
definido no plano de gerenciamento do projeto e implementa as mu¬ 
danças aprovadas para atingir os seus objetivos. 

□ Realizar a garantia da qualidade : audita os requisitos de qualidade e 
os resultados da medição do controle da qualidade para garantir que 
sejam usados os padrões de qualidade e as definições operacionais 
apropriadas. 

□ Mobilizar a equipe do projeto : confirma a disponibilidade dos recur¬ 
sos humanos e obtém a equipe necessária para terminar as atividades 
do projeto. 

□ Desenvolver a equipe do projeto : realiza a melhoria de competências, 
da interação da equipe e do ambiente geral da equipe para aprimorar 
o desempenho do projeto. 

□ Gerenciar a equipe do projeto : acompanha o desempenho dos mem¬ 
bros da equipe, fornece feedback , resolve questões e gerencia mudan¬ 
ças para otimizar o desempenho do projeto. 












Modelos para Gerenciamento de Projetos 355 


□ Gerenciar as comunicações : cria, coleta, distribui, armazena, recupera 
e finalmente disponibiliza as informações do projeto de acordo com o 
plano de gerenciamento de comunicações. 

□ Conduzir aquisições: obtém respostas dos fornecedores, seleciona um 
fornecedor e adjudica o contrato. 

□ Gerenciar o engajamento das partes interessadas ; comunica-se e tra¬ 
balha com as partes interessadas para atender às suas necessidades/ex- 
pectativas, aborda as questões à medida que elas ocorrem e incentiva 
o engajamento apropriado das partes interessadas nas atividades do 
projeto, no decorrer de todo o ciclo de vida do projeto. 


9.1.3.2.4 Grupo de processos de monitoramento e controle 

Consiste nos processos requeridos para acompanhar, analisar e organizar 
o progresso e o desempenho do projeto, identificar quaisquer áreas nas quais 
mudanças no plano são requeridas e iniciar as mudanças correspondentes. 

□ Monitorar e controlar o trabalho do projeto : acompanha, avalia e 
regula o progresso para atender aos objetivos de desempenho de¬ 
finidos no plano de gerenciamento do projeto. O monitoramento 
inclui relatórios de status , medições de progresso e previsões. Os 
relatórios de desempenho fornecem informações sobre o desempe¬ 
nho do projeto com relação a escopo, cronograma, custo, recursos, 
qualidade e risco, que podem ser usadas como entradas para outros 
processos. 

□ Realizar o controle integrado de mudanças : avalia todas as solicita¬ 
ções de mudança, realiza a aprovação e o gerenciamento de mudanças 
nas entregas, nos ativos de processos organizacionais, nos documen¬ 
tos e planos de gerenciamento do projeto, e comunica as decisões 
sobre estes. 

□ Validar o escopo : formaliza a aceitação das entregas terminadas do 
projeto. 

□ Controlar o escopo : monitora o andamento do escopo do projeto 
e do produto e gerencia as mudanças feitas na linha de base do 
escopo. 
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□ Controlar o cronograma : monitora o andamento do projeto para 
atualização do seu progresso e gerencia as mudanças feitas na linha de 
base do cronograma para realizar o planejado. 

□ Controlar os custos : monitora o andamento do projeto para atualiza¬ 
ção do seu orçamento e gerencia as mudanças feitas na linha de base 
dos custos. 

□ Controlar a qualidade : monitora e registra os resultados da execução 
das atividades de qualidade para avaliar o desempenho e recomendar 
as mudanças necessárias. 

□ Controlar as comunicações : monitora e controla as comunicações no 
decorrer de todo o ciclo de vida do projeto para assegurar que as 
necessidades de informação das partes interessadas do projeto sejam 
atendidas. 

□ Controlar os riscos : implementa planos de respostas aos riscos, 
acompanha os riscos identificados, monitora os riscos residuais, 
identifica novos riscos e avalia o processo de risco durante todo o 
projeto. 

□ Controlar as aquisições : gerencia os relacionamentos das aquisições 
e monitora o desempenho dos contratos, fazendo mudanças e corre¬ 
ções quando necessário. 

□ Controlar o engajamento das partes interessadas : monitora os rela¬ 
cionamentos das partes interessadas do projeto em geral e ajusta as 
estratégias e os planos para o engajamento das partes interessadas. 

9.1.3.2.5 Grupo de processos de encerramento 

Consiste nos processos que finalizam todas as atividades por todos os gru¬ 
pos de processo de gerenciamento, visando concluir formalmente o projeto, a 
fase ou as obrigações contratuais. 

□ Encerrar o projeto ou fase : finaliza todas as atividades de todos os 
grupos de processos de gerenciamento para terminar formalmente o 
projeto ou a fase. 

□ Encerrar as aquisições : finaliza cada aquisição do projeto. 
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9 . 1.4 Aplicabilidade do modelo 

O corpo de conhecimento em gerenciamento de projetos pode ser aplica¬ 
do em projetos de qualquer natureza (inclusive para qualquer tipo de projeto 
de tecnologia da informação, que é nosso interesse aqui). Com suas devidas 
adaptações, pode ser empregado para o gerenciamento de grandes empreen¬ 
dimentos até pequenos projetos. 

A ênfase do modelo é sobre a gestão de projetos e não sobre a enge¬ 
nharia de desenvolvimento do produto resultante do projeto. Por exem¬ 
plo, podemos utilizar o modelo para a gestão dos projetos de software e 
sistemas, mas não para o processo metodológico do desenvolvimento do 
software. 

O PMBOK, para ser utilizado de forma consistente em uma organização 
de TI, necessita de adaptações em função dos tipos, portes e riscos dos pro¬ 
jetos. Além do mais, deve ser estabelecido um processo de gerenciamento de 
projetos que interligue, de forma lógica e coerente, as boas práticas entre si. 
Adicionalmente, formulários específicos devem ser elaborados ou customi¬ 
zações de ferramentas específicas de gerenciamento de projetos podem ser 
necessárias para o uso do processo. 

O modelo é suportado por ferramentas de gerenciamento de projetos exis¬ 
tentes no mercado, sendo que algumas podem apoiar total ou parcialmente as 
boas práticas do modelo. 

Como toda inovação, a implantação do gerenciamento de projetos na or¬ 
ganização também não é uma tarefa fácil. Necessita de forte comprometi¬ 
mento das lideranças da organização e dos executivos e gerentes de TI. Nossa 
experiência tem demonstrado isso, até mesmo em organizações onde executar 
projetos é o fator-chave do negócio. 

Nossa experiência na implantação de escritório de projetos e de metodolo¬ 
gias e processos de gerenciamento de projetos tem demonstrado que há fortes 
resistências, tanto do pessoal de TI como do pessoal de negócios, para adotar 
novas formas de gerenciar projetos. Geralmente não são processos sustentá¬ 
veis. O padrão, a metodologia, etc. podem até existir, mas não são seguidos 
de forma consistente. 

Em grande parte das empresas, às vezes apenas alguns elementos do pro¬ 
cesso de gerenciamento de projetos são colocados no seu sistema de controle 
interno e são objeto de verificação de conformidade periódica. 
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9 . 1.5 Benefícios do modelo 

De acordo com uma pesquisa realizada pelo Center for Business Practices 
(2013) em organizações de variados portes, os seguintes benefícios foram ob¬ 
tidos com a implantação da gestão de projetos: 

□ 28% foi o retorno do investimento (ROI); 

□ 38% foi a melhoria na satisfação do cliente; 

□ 37% foi a melhoria do alinhamento dos projetos com os objetivos 
estratégicos; 

□ 22% foi a melhoria no tempo de lançamento de produtos e serviços; 

□ 33% foi a melhoria nas estimativas de prazo e custo; 

□ 32% foi a melhoria no desempenho do cronograma; 

□ 32% foi a melhoria na qualidade; 

□ 26% foi a melhoria no uso de recursos humanos; 

□ 24% foi a melhoria no custo; 

□ 23% foi a melhoria na produtividade das pessoas; 

□ 38% foi a melhoria na estimativa de prazo; 

□ 33% foi a melhoria na estimativa do custo-hora; 

□ 13% foi a melhoria na estimativa de defeitos. 

9 . 1.6 Certificações relacionadas 

O Project Management Institute mantém várias certificações profissionais 
relativas a gerenciamento de projetos: 

□ O Project Management Professional (ou PMP, como é mais conheci¬ 
do), voltado para gerentes de projetos. 

□ O Certified Associate in Project Management (ou CAPM), projetado 
para gerentes de projetos iniciantes e para profissionais que partici¬ 
pam de projetos, mas sem responsabilidade pelo gerenciamento. 

□ PMIAgile Certified Practitioner (ou PMI-ACP). 

□ PMI Risk Management Professional (ou PMI-RMP). 

□ PMI Scheduling Professional (ou PMI-SP). 

Cabe atentar para o fato de que o PMI não certifica a organização, somente 
profissionais. 
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9.2 Padrão para Gestão de Portfólio 

9 . 2.1 Histórico do modelo 

Este padrão nasceu da necessidade de prover as organizações de instrumen¬ 
tos que lhe possibilitem a ligação da estratégia de negócio com a sua realização 
e faz parte de um processo de maturidade organizacional, em relação ao cam¬ 
po da gestão de projetos. 

Em 2003, foi identificada a necessidade de criação de um padrão para 
portfólio de Projetos, juntamente com o de Programas. 

Neste mesmo ano, foi formada equipe responsável por desenvolver o novo 
padrão. Entre maio e julho de 2005, o padrão foi publicado e mantido como 
Exposure Drafi para colher sugestões da comunidade mundial de gestão de 
projetos, recebendo cerca de 455 comentários e sugestões (mais da metade 
foi aprovada e incorporada). Em outubro de 2005, o padrão foi submetido à 
aprovação pela Equipe de Padrões do PMI. 

Participaram como voluntários na realização do padrão 416 profissio¬ 
nais, membros do PMI, representando 36 países. Em 2006, o padrão foi 
publicado e entregue à comunidade internacional. Agora já se encontra em 
sua terceira edição, publicada em 2013, alinhada com a última versão do 
PMBOK. 

9 . 2.2 Objetivos do modelo 

O objetivo do modelo é descrever melhores práticas, reconhecidas generi¬ 
camente, associadas ao gerenciamento do portfólio. Genericamente reconhe¬ 
cidas significa que o conhecimento e as práticas descritas são aplicáveis, na 
maior parte do tempo, na maioria dos portfólios, sendo que há um grande 
consenso sobre a sua utilidade e valor. 

Sua aplicação é intencionada para qualquer tipo de organização (privadas, 
terceiro setor e governamentais). 
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9.2.3 Estrutura do modelo 

9.2.3.1 Conceitos de Gestão de Portfólio 

De acordo com o padrão, Gestão de Portfólio é: “uma coleção de projetos 
e/ou programas e outros trabalhos que são agrupados para facilitar a gestão 
efetiva do trabalho para atender aos objetivos estratégicos do negócio”. A Fi¬ 
gura 9.3 mostra este conceito. 



Programas 


Projetos 


Subprogramas 


Projetos 


Operações 



Projetos 


Projetos 


Projetos 


Figura 9.3 - Portfólio, Programas e Projetos - Visão Geral 
Adaptado de PMI (2013b) 


Outras características do Portfólio são: 

□ Compreende iniciativas atuais e futuras. 

□ Não é temporário como projetos e programas. 

□ A organização pode ter vários portfólios (como portfólio de TI, para 
uma área específica). 

□ Em determinado momento, o portfólio reflete os objetivos estratégi¬ 
cos da organização. 

□ Compreende os trabalhos que têm que ser feitos e não os que devem 
ser feitos. 
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O gerenciamento do portfólio é a gestão coordenada dos componentes 
do portfólio para atingir os objetivos organizacionais específicos. 

No contexto organizacional, o portfólio de projetos é o que faz a liga¬ 
ção da estratégia da organização com a operação. A Figura 9.4 mostra esta 
ligação. 



Figura 9.4 - 0 contexto organizacional do gerenciamento do portfólio 
Adaptado de PMI (2013b) 
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9.2.3.2 Visão geral do modelo 

O modelo, analogamente ao PMBOK, especifica grupos de processos e 
áreas de conhecimento, conforme apresentado na Tabela 9.2, a seguir. 


Grupos de Processos 

Áreas de Conhecimento 

Grupo de Processos 
de Definição 

Grupo de Processos 
de Alinhamento 

Grupo de Processos de 
Autorização e Controle 

Gerenciamento 

Estratégico do Portfólio 

4.1 Desenvolver o 
plano estratégico do 
portfólio 

4.4 Gerenciar 
mudanças estratégicas 


4.2 Termo de abertura 
do portfólio 

4.3 Definir o roadmap 
do portfólio 

Gerenciamento da 
Governança do Portfólio 

5.1 Desenvolver 
o plano de 
gerenciamento do 
portfólio 

5.3 Otimizar o portfólio 

5.4 Autorizar o portfólio 

5.2 Definir o portfólio 

5.5 Prover fiscalização do 
portfólio 

Gerenciamento do 
Desempenho do Portfólio 

6.1 Desenvolver plano 
de gerenciamento 
do desempenho do 
portfólio 

6.2 Gerenciar 
fornecimento e 
demanda 


6.3 Gerenciar o valor do 
portfólio 

Gerenciamento da 
Comunicação do Portfólio 

7.1 Desenvolver plano 
de gerenciamento 
da comunicação do 
portfólio 

7.2 Gerenciar a 
informação do portfólio 

Gerenciamento do Risco 
do Portfólio 

8.1 Desenvolver plano 
de gerenciamento dos 
riscos do portfólio 

8.2 Gerenciar os riscos 
do portfólio 



Tabela 9.2 - Mapeamento dos grupos de processos, 
processos e áreas de conhecimento Adaptado de PMI (2013b) 


Os grupos de processos são apresentados nas seções seguintes: 
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9.2.3.3 Grupo de processos de definição 

Consiste dos processos executados para estabelecer como a estratégia e ob¬ 
jetivos organizacionais serão implementados no portfólio. A seguir, esses pro¬ 
cessos são descritos brevemente: 

□ Desenvolver o plano estratégico do portfólio: avalia as estratégias e 
decisões de investimentos e define a estratégia do portfólio em rela¬ 
ção a esses objetivos e estratégias no plano estratégico do portfólio. 

□ Termo de abertura do portfólio: cria o termo de abertura do portfó¬ 
lio, identificando a estrutura e a equipe de gestão do portfólio, visan¬ 
do o alinhamento com o plano estratégico do portfólio. 

□ Definir o roadmap do portfólio: cria um cronograma em alto nível 
mostrando o plano estratégico para os componentes a serem imple¬ 
mentados ao longo do tempo com as dependências entre esses com¬ 
ponentes, de forma que a gestão possa avaliar conflitos ou gaps entre 
o roadmap e os objetivos/estratégias organizacionais. 

□ Desenvolver o plano de gerenciamento do portfólio: define os 
componentes do portfólio, desenvolvendo a estrutura organizacio¬ 
nal de gestão do portfólio e o plano de gerenciamento do portfólio. 

□ Definir o portfólio: cria e organiza os componentes do portfólio para 
serem avaliados, selecionados e priorizados. 

□ Desenvolver o plano de gerenciamento do desempenho do portfó¬ 

lio: desenvolve o plano de gerenciamento do desempenho (conside¬ 
rando como o valor do portfólio será definido e executado através 
de medições e metas do portfólio), o alinhamento com as estratégias 
e objetivos e os papéis e responsabilidades na execução do plano. 

□ Desenvolver o plano de gerenciamento da comunicação do portfólio: 

inclui a identificação das partes interessadas, assim como o planeja¬ 
mento de soluções efetivas para satisfazer os requisitos de comunicação. 

□ Desenvolver o plano de gerenciamento dos riscos do portfólio: plane- 
ja a gestão dos riscos, incluindo a identificação dos riscos do portfólio, 
proprietários dos riscos do portfólio 88 , tolerância a riscos 89 e a criação 
dos processos de gerenciamento de riscos. 


88 No momento da identificação dos riscos deve-se definir o responsável pelo seu tratamento e pela 
execução de ações de minimização dos impactos dos riscos ou ações de contingências. 

89 Tolerância aos riscos significa estabelecer até que montante a administração da empresa aceita 
perder, se o risco ocorrer. 
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9.2.3.4 Grupo de processos de alinhamento 

Os processos deste grupo devem garantir o gerenciamento e a otimização 
do portfólio, assim como o alinhamento dos projetos e programas aos objeti¬ 
vos estratégicos da organização. De acordo com o padrão, o alinhamento deve 
ser realizado durante o planejamento anual da empresa. 

□ Gerenciar as mudanças estratégicas : avalia e determina as respostas 
às mudanças na estratégia e no portfólio da organização e atualiza o 
plano de gerenciamento do portfólio e planos subsidiários para re¬ 
fletir os impactos e as respostas para os processos de gerenciamento 
do portfólio. 

□ Otimizar o portfólio: revê, analisa e muda os componentes do por- 
tfólio para criar um balanço para atender às estratégias e aos objetivos 
organizacionais. 

□ Gerenciar o fornecimento e demanda : identifica e aloca as capaci¬ 
dades e competências dos recursos necessários para o portfólio, de 
acordo com cada proposta de componente e respectivo plano. 

□ Gerenciar o valor do portfólio: mede, captura, valida e comunica o valor 
produzido pelos componentes, com o objetivo de maximizar o retorno 
do investimento, considerando um nível aceitável de risco. 

□ Gerenciar a informação do portfólio: executa o plano de comu¬ 
nicação pela coleta de dados, traduzindo os dados em informação 
útil, e a fornece às partes interessadas de uma maneira efetiva e 
tempestiva. 

□ Gerenciar os riscos do portfólio: executa o plano de gerenciamen¬ 
to dos riscos, incluindo avaliação, respostas e monitoramento dos 
riscos. 


9.2.3.5 Grupo de processos de autorização e controle 

Este grupo de processos conduz as atividades necessárias para assegurar 
que o portfólio como um todo está sendo executado conforme as métricas 
determinadas pela organização. 
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□ Autorizar o portfólio: alocar os recursos para desenvolver as propostas 
dos componentes, autorizar os componentes a incorrerem em despe¬ 
sas e comunicar as decisões do portfólio. 

□ Prover fiscalização do portfólio: monitorar o portfólio para assegu¬ 
rar seu alinhamento com as estratégias e os objetivos da organização, 
realizando decisões de governança em resposta ao desempenho do 
portfólio, a mudanças nos componentes do portfólio, a problemas e 
riscos para assegurar que o portfólio está alinhado com o roadmap , 
progresso atual e condições (recursos). 

9.2.4 Aplicabilidade do modelo 

O padrão pode ser aplicado em organizações que percebem que a reali¬ 
zação da estratégia do negócio deve ser implementada a partir de iniciativas 
representadas por programas e projetos. 

Um aspecto importante do conceito é que a implantação das iniciativas 
que vão concretizar a estratégia da empresa ou instituição deve maximizar o 
retorno esperado, seja este financeiro, social e/ou de outras naturezas. 

Podemos empregar este conceito para TI, no contexto do Portfólio de TI, 
que não deixa de ser um portfólio de investimentos e que também tem pro¬ 
jetos e programas. 

Acreditamos que o gerenciamento de portfólio é o principal instrumento 
para o alinhamento dos projetos e das iniciativas às estratégias do negócio e 
que sua implantação deve ser perseguida por toda organização, eliminando 
aquilo que não agrega valor. 

Entretanto, um bom desempenho do portfólio depende de uma boa gestão 
dos projetos e programas. 


9.2.5 Benefícios do modelo 

O que significa não ter um Portfólio de Projetos? 

□ Muitas demandas sem alinhamento com o negócio. 

□ Aumento do custo da operação, pois toda demanda é tratada por TI, 
independentemente de sua importância para o negócio. 

□ Os bons projetos podem “morrer de fome”, sem recursos. 
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□ Projetos errados sáo selecionados. 

□ Muitos projetos cancelados, pois se descobre muito mais tarde que 
não eram prioritários. 

□ Os novos produtos podem não estar dando suporte à estratégia etc. 

Acreditamos que ficam óbvios para o leitor a importância e os benefícios 
de ter um Portfólio de Projetos. 

A experiência dos autores em suas observações em diversas organizações 
empresariais e outras instituições governamentais atesta que um dos grandes 
problemas de TI é a gestão da demanda de serviços, principalmente para siste¬ 
mas. O Portfólio de TI resolveria grande parte deste problema, que atormenta 
todos os CIOs. 


9.2.6 Certificações relacionadas 

Ainda não há certificações específicas relacionadas à Gestão de Portfólio 
de Projetos. 


9.3 Padrão para Gestão de Programas 

9.3.1 Histórico do modelo 

Este padrão nasceu da necessidade de prover as organizações de instrumen¬ 
tos que lhe possibilitem a gestão integrada de projetos cujos benefícios sejam 
correlacionados. 

Em 2003, foi identificada a necessidade de criação de um padrão para Ges¬ 
tão de Programas, juntamente com o de Gestão de Portfólio, e foi formado o 
grupo para o seu desenvolvimento. Este padrão começou a ser desenvolvido 
em 2004 e seu primeiro draft foi finalizado neste mesmo ano. 

Entre março e agosto de 2005, o padrão foi publicado e mantido como 
Exposure Draft para colher sugestões da comunidade mundial de gestão de 
projetos, recebendo cerca de 465 comentários e sugestões (mais da metade 
foi aprovada e incorporada). Em dezembro de 2005 o padrão foi submetido à 
aprovação da Equipe de Padrões do PMI. 
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Participaram como voluntários na realização do padrão 416 profissionais, 
membros do PMI, representando 36 países. Em 2006, o padrão foi publicado 
e entregue à comunidade internacional. Em 2008 foi publicada a segunda 
edição deste padrão. A terceira edição foi publicada em 2013. 


9.3.2 Objetivos do modelo 

Este padrão descreve como a estratégia organizacional estabelece a funda¬ 
ção para o gerenciamento dos programas e portfólios. Fornece informações 
sobre a gestão de programas que é aceita geralmente como boas práticas para 
a maioria dos programas a maior parte do tempo. Boa prática significa que há 
um consenso sobre o seu valor e utilidade. 

As abordagens, as atividades e os processos documentados neste padrão 
são geralmente aceitos como etapas necessárias para o gerenciamento bem- 
-sucedido de programas. 


9.3.3 Estrutura do modelo 

9.3.3.1 Conceituação da Gestão de Programas 

De acordo com PMI (2013c): 

□ Um programa é: “um conjunto de projetos relacionados, subprogra- 
mas e atividades de programas que são gerenciados de uma forma 
coordenada para obter os benefícios não disponíveis se fossem geren¬ 
ciados individualmente”. 

□ A gestão de programas é: “a aplicação de conhecimento, habilidades, 
ferramentas e técnicas para um programa para atender a seus requi¬ 
sitos e para obter os benefícios e controles não disponíveis se fossem 
gerenciados individualmente”. 

A Gestão de Programas está focada na gestão dos benefícios a serem atingi¬ 
dos pelo Programa a partir da contribuição individual de cada projeto, como 
mostra a Figura 9.5. 
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Figura 9.5 - Gestão dos benefícios do programa 
Adaptado de PMI (2013c) 
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9.3.3.2 Domínios e processos de suporte 

O padrão, agora em sua terceira edição, define domínios de desempenho 
do programa e processos de suporte ao gerenciamento do programa. 

Os domínios de desempenho são: 

□ Alinhamento da estratégia do programa : identifica oportunidades e 
benefícios para alcançar os objetivos estratégicos da organização atra¬ 
vés da implantação de um programa. 

□ Gerenciamento dos benefícios do programa : define, cria, maximiza, 
entrega e sustenta os benefícios proporcionados pelos programas. 

□ Engajamento das partes interessadas ao programa : captura e entende 
as necessidades das partes interessadas, desejos e expectativas, e ana¬ 
lisa o impacto do programa sobre as partes interessadas, ganhando 
e mantendo o apoio das partes interessadas, gerenciando a comuni¬ 
cação com as partes interessadas e mitigando a resistência das partes 
interessadas. 
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□ Governança do programa : estabelece processos e procedimentos para 
manter a fiscalização da gestão do programa e a tomada de decisão 
sobre políticas e práticas aplicáveis ao longo do desenvolvimento do 
programa. 

□ Gerenciamento do ciclo de vida do programa : gerencia todas 
as atividades do programa relacionadas à definição do progra¬ 
ma, à entrega dos benefícios do programa e ao encerramento do 
programa. 

A Tabela 9.3 apresenta os elementos de cada domínio e seus principais 
produtos. 


Domínio 

Atividades 

Produtos 


Estratégia organizacional e 

• Business Case do programa 90 


alinhamento do programa 

• Plano do programa 

Alinhamento da 
estratégia do 
programa 

Roadmap do programa 

• Representação cronológica da direção do 
programa 

Avaliações ambientais 

• Fatores ambientais da empresa 


• Análise do ambiente 


Identificação dos benefícios 

• Business Case 

• Registro dos benefícios 



• Plano de realização dos benefícios 


Planejamento e análise dos benefícios 

• Gerenciamento dos benefícios 

Gerenciamento 
dos benefícios 
do programa 

• Registro das atualizações do registro dos 
benefícios 

Entrega dos benefícios 

• Relação dos benefícios e dos componentes 
do programa 


• Relação dos benefícios e da governança do 
programa 


Transição do programa 



Sustentação do programa 



90 O Business Case demonstra a análise do investimento e seu retorno. 
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Domínio 

Atividades 

Produtos 

Engajamento 
das partes 
interessadas ao 
programa 

Identificação das partes interessadas 
do programa 91 

• Registro das partes interessadas 

Planejamento do engajamento das 
partes interessadas 

• Plano de engajamento 

Engajamento das partes interessadas 

• Monitoramento do engajamento 

Governança do 
programa 

Comitê de Governança do Programa 

• Comitê de governança do programa 

Responsabilidades do Comitê de 
Governança do Programa 

• Aprovação do programa 

• Iniciação do programa 

• Financiamento do programa 

• Plano de governança 

• Critérios de sucesso do programa 

• Abordagem de aprovação 

• Suporte ao desempenho do programa 

• Assegurar os processos de comunicação e 
controle 

• Assegurar o planejamento da qualidade 

• Assegurar o monitoramento do progresso e a 
necessidade por mudança 

• Instituir o escritório do programa 

Gerenciamento 
do ciclo de vida 
do programa 

Fase de definição do programa 

• Formulação do programa 

• Preparação do programa 

Fase de entrega dos benefícios do 
programa 

• Planejamento e autorização do componente 

• Integração e fiscalização do componente 

• Transição do componente 

Fase de encerramento do programa 

• Transição do programa 

• Encerramento dos contratos do programa 


Tabela 9.3 - Domínios de desempenho 
Adaptado de PMI (2013c) 


A seguir sáo relacionados os processos de suporte ao gerenciamento 
do programa, assim como as atividades incluídas no contexto de cada 
processo: 

□ Gerenciamento da comunicação do programa : facilitar a geração 
apropriada e no tempo requerido da coleta, da distribuição, do ar- 


91 Partes interessadas ( stakeholders ) do programa podem ser: patrocinador do programa, Comitê 
de Governança do programa, gerente do programa, gerente dos projetos, equipes do programa e dos 
projetos, financiadores do programa, clientes, clientes potenciais, gestores de negócio, fornecedores, 
agências de governo etc. 
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mazenamento, da recuperação e da disposição final das informações 
do programa. 

□ Gerenciamento financeiro do programa : identificar as fontes e os re¬ 
cursos financeiros, integrar os orçamentos dos componentes, desen¬ 
volver o orçamento integrado do programa e controlar os custos ao 
longo da duração dos componentes e do programa. 

□ Gerenciamento da integração do programa : identificar, definir, 
combinar, unificar e coordenar múltiplos componentes dentro do 
programa. 

□ Gerenciamento das aquisições do programa : procurar e selecionar 
produtos e serviços para assistir na entrega dos benefícios. 

□ Gerenciamento da qualidade do programa : determinar políticas da 
qualidade, objetivos e responsabilidades de forma que o programa 
seja bem-sucedido. 

□ Gerenciamento dos recursos do programa : assegurar que todos os 
recursos necessários para o programa estejam disponíveis aos geren¬ 
tes de projetos de forma que possam entregar os benefícios para o 
programa. 

□ Gerenciamento dos riscos do programa : planejar, identificar, analisar, 
responder e monitorar os riscos. 

□ Gerenciamento do cronograma do programa : determinar a ordem 
de desenvolvimento dos componentes, realizar estimativas de tempo 
para cada componente, identificar os principais marcos de controle, 
cronograma etc. 

□ Gerenciamento do escopo do programa : planejar e gerenciar o escopo 
do programa em termos de decompor em componentes (projetos) 
necessários para entregar os benefícios. 


9333 Relacionamento entre os processos de suporte e o ciclo de 
vida do programa 

A Tabela 9.4 apresenta a relação dos processos de suporte com as atividades 
do ciclo de vida do programa. 
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Processos de Suporte 

Fases do Ciclo de Vida do Programa 

Definição do 
Programa 

Entrega dos 
Benefícios do 
Programa 

Encerramento do 
Programa 

8.1 Gerenciamento 
das comunicações do 
programa 

8.1.1 Planejamento da 
comunicação 

8.1.2 Distribuição da 
informação 

8.1.3 Comunicação do 
desempenho do programa 


8.2 Gerenciamento 
financeiro do programa 

8.2.1 Estimativa dos 
custos do programa 

8.2.2 Estabelecimento 
do modelo financeiro do 
programa 

8.2.3 Desenvolvimento do 
plano de gerenciamento 
financeiro 

8.2.4 Estimativa do curso 
do componente 

8.2.5 Orçamento do custo 
do programa 

8.2.6 Controle e 
monitoramento financeiro 
do programa 

8.2.7 Encerramento 
financeiro do programa 

8.3 Gerenciamento da 
integração do programa 

8.3.1 Iniciação do 
programa 

8.3.2 Desenvolvimento do 
plano de gerenciamento 
do programa 

8.3.3 Desenvolvimento 
da infraestrutura do 
programa 

8.3.4 Gerenciamento da 
execução do programa 

8.3.5 Monitoramento e 
controle do desempenho 
do programa 

8.3.6 Transição do 
programa e sustentação 
dos benefícios 

8.3.7 Encerramento do 
programa 

8.4 Gerenciamento da 
aquisição do programa 

8.4.1 Planejamento das 
aquisições do programa 

8.4.2 Aquisições do 
programa 

8.4.3 Administração das 
aquisições do programa 

8.4.4 Encerramento das 
aquisições do programa 

8.5 Gerenciamento da 
qualidade do programa 

8.5.1 Planejamento da 
qualidade do programa 

8.5.2 Garantia da 
qualidade do programa 

8.5.3 Controle da 
qualidade do programa 


8.6 Gerenciamento dos 
recursos do programa 

8.6.1 Planejamento de 
recursos 

8.6.2 Priorização de 
recursos 

8.6.3 Gerenciamento da 
interdependência dos 
recursos 
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Processos de Suporte 

Fases do Ciclo de Vida do Programa 

Definição do 
Programa 

Entrega dos 
Benefícios do 
Programa 

Encerramento do 
Programa 

8.7 Gerenciamento dos 
riscos do programa 

8.7.1 Planejamento do 
gerenciamento dos riscos 
do programa 

8.7.2 Identificação dos 
riscos do programa 

8.7.3 Análise dos riscos 
do programa 

8.7.4 Planejamento das 
respostas aos riscos do 
programa 

8.7.5 Monitoramento e 
controle dos riscos do 
programa 


8.8 Gerenciamento do 
cronograma do programa 

8.8.1 Planejamento do 
cronograma do programa 

8.8.2 Controle do 
cronograma do programa 


8.9 Gerenciamento do 
escopo do programa 

8.9.1 Planejamento do 
escopo do programa 

8.9.2 Controle do escopo 
do programa 



Tabela 9.4 - Mapeamento das atividades do ciclo de vida com os processos de suporte 

Adaptado de PMI (2013c) 


9.3.4 Aplicabilidade do modelo 


Na área de TI, este modelo pode ser aplicado em situações como: 

□ Desenvolvimento e implantação do Programa de Governança de TL 

□ Desenvolvimento de uma nova plataforma de produto para a organização. 

□ Implantação de uma nova arquitetura de sistemas na organização. 

□ Implantação dos processos de gerenciamento de serviços. 

□ Implantação de um Programa de Segurança da Informação global 
para a organização etc. 


Há situações em que os executivos de TI planejam atingir determinados 
objetivos e metas em um período de médio e longo prazos. Nesse caso, é im¬ 
portante identificar a necessidade da existência de um programa. 
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9.3.5 Benefícios do modelo 

A Gestão de Programas permite a consolidação de projetos que, juntos, 
podem fornecer um foco e melhor direcionamento de investimentos para a 
organização de TL 

Uma visão de programas facilita o planejamento do atendimento aos ob¬ 
jetivos de TI através da realização coordenada dos benefícios de cada projeto, 
além de fornecer um “norte” seguro para os empreendimentos de TL 

Por exemplo, em um empreendimento de Segurança da Informação, exis¬ 
tem vários projetos que ocorrem em tempos diferentes, sendo que um é base 
para o outro até que os objetivos de gestão de risco da empresa tenham sido 
atingidos. Deve-se começar por analisar vulnerabilidades, definir a política e 
o framework de gerenciamento da segurança da informação e elaborar o pla¬ 
nejamento; e continuar com a implantação de projetos de conscientização, a 
estruturação da área de segurança da informação, a implantação dos contro¬ 
les e políticas etc. Geralmente é um processo que dura de dois a três anos e, 
em algumas situações, dependendo do porte da organização, até mais tempo. 

Além disso, com uma visão de programa de longo prazo, fica mais facilita¬ 
da a tarefa de negociar recursos para os projetos que constituem o programa. 

Entretanto, deve haver um forte patrocínio para que o programa seja estru¬ 
turado e conduzido. Não é costume no Brasil esperar por resultados de longo 
prazo, principalmente na área de TL 

Em nível de governo, o conceito de programa é mais difundido, pois toda 
ação governamental é baseada em programas de longa duração, como é o caso 
do PAC, Bolsa Família, Fome Zero etc. 


9.3.6 Certificações relacionadas 

O PMI tem a certificação profissional denominada PgMP ou Program 
Management Professional. 

O processo é similar ao do PMP, porém a elegibilidade é bastante pesada. 
Para profissionais com diploma de nível superior, são exigidos quatro anos (ou 
6.000 horas) de experiência em gestão de projetos e quatro anos (ou 6.000 
horas) de experiência em gestão de programas. Para aqueles que só têm diplo¬ 
ma de segundo grau, são requeridos quatro anos de experiência em gestão de 
projetos e sete anos (ou 10.500 horas) em gestão de programas. 
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Acreditamos que este certificado é um diferencial, na medida em que esse 
padrão for praticado nas organizações de uma forma geral. 


9.4 Outros padrões do PMI 

Além dos citados, o PMI edita vários outros padrões, que na maioria das vezes 
se tornam padrões americanos pela American National Standard Institute - ANSI. 
A seguir, fornecemos uma lista: 

□ Extensão do PMBQK para o Governo : aplicado para projetos no 
governo. 

□ Extensão do PMBQK para Construção : aplicado para projetos de 
construção de obras. 

□ Modelo de Maturidade Organizacional em Gestão de Projetos ( Orm - 

nizational Project Management Maturity Model - QPM3.) : fornece as 
ferramentas necessárias para as organizações medirem sua maturidade 
em relação a um conjunto de melhores práticas. 

□ Padrão de Gestão de Valor {Practice for Earned Value Management ): 

padrão que trata da medição de valor do projeto em termos de custo, 
prazo e escopo, usado para fornecer indicadores do status do projeto. 

□ Padrão para a Gestão de Configuração do Projeto {Practice for Project 

Confimration Management) : padrão que auxilia os gerentes de projetos 
a gerenciar os itens que são gerados ao longo do ciclo de vida do projeto. 

□ Padrão para Estrutura Analítica do Trabalho ( Practice Standard for 

Work Breakdown Structuré) -. padrão para auxiliar na elaboração de 
Work Breakdown Structuré - WBS. 

□ Esquema de Desenvolvimento de Competências para Gerente de 

Projeto [Project Manager Competency Development Framework) -. pa¬ 

drão que auxilia os gerentes de projeto e as organizações a expandir as 
suas competências em gerenciamento de projetos. 

□ Padrão para Gerenciamento de Riscos de Projetos ( Practice Standard 

for Project Risk Management) : fornece um benchmarking para o geren¬ 
te de projetos que define os aspectos do gerenciamento de riscos de 
projetos considerados como boas práticas para a maioria dos projetos. 

□ Padrão para Estimativas de Projetos ( Practice Standard for Project Es- 

timatim) : descreve o ciclo de vida da estimativa para o projeto, deta- 
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lhando os aspectos de recursos, durações e custos e explica o conceito 
de elaboração progressiva na medida em que o projeto evolui. 

□ Padrão para Elaboração do Cronograma ( Practice Standard for Schedul- 

im) : apresenta ferramentas e informação de que os gerentes de projetos 
necessitam para elaborar um cronograma de forma eficiente e eficaz. 

Por fim, o PMI está sempre inovando na atualização permanente dos mo¬ 
delos atuais, assim como no desenvolvimento de novos padrões. Para mais 
informações sobre os padrões do PMI, ver a página www.pmi.org. 


9.5 PRIIMCE2 

9.5.1 Histórico do modelo 

A PRINCE ( Projects in Controlled Environments ) foi estabelecida primei¬ 
ramente em 1989 pelo CCTA ( Central Computer and Telecommunications 
Agency) do governo britânico. 

A metodologia PRINCE foi desenvolvida a partir da PROMPTII, uma me¬ 
todologia de gerenciamento de projetos criada pela empresa Simpact Systems 
Ltda. em 1975, a qual foi adotada pelo CCTA em 1979 como padrão para 
uso por todos os projetos de sistemas de informação do governo. A PRINCE 
sucedeu a PROMPTII em 1989 para os projetos do governo britânico. 

O CCTA, incorporado ao Office of Government Commerce 92 , continuou o 
desenvolvimento da metodologia e a PRINCE2 foi lançada em 1996, em res¬ 
posta aos requisitos dos usuários para melhorar a orientação de gestão de proje¬ 
tos para todos os tipos de projeto, além dos projetos de sistemas de informação. 

Em 2002, foi lançada a terceira edição da metodologia e, em 2005, a quar¬ 
ta edição. 

Atualmente encontra-se em sua quinta edição, publicada em 2009. 

Da mesma forma que o PMBOK, a PRINCE2 também possui o seu mo¬ 
delo de maturidade. A metodologia PRINCE2 é baseada nas experiências 
com os projetos, gerentes de projetos e equipes de projeto que contribuíram 
com os seus erros, acertos e sucessos. 

A metodologia atualmente é, de fato, o padrão usado pelo governo britânico, 
sendo também reconhecida e usada no setor privado, principalmente na Europa. 


92 Atualmente, o OGC e suas funções foram movidos para o The Cabinet Office do governo britânico. 
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9.5.2 Objetivos do modelo 

O objetivo da PRINCE2 é fornecer um método que: 

□ Possa ser repetido por todos os projetos. 

□ Possa ser ensinado. 

□ Assegure que os membros dos projetos saibam o que esperar deles, 
onde, como e quando. 

□ Previna mais cedo contra problemas no projeto. 

□ Permita ser proativo, não reativo, mas capaz de acomodar mudanças 
repentinas, oriundas de eventos inesperados. 

□ Forneça um guia consistente para os gerentes de projetos e demais 
interessados, facilitando o planejamento, o controle e a comunicação 
no âmbito do projeto. 


9.5.3 Estrutura do modelo 

A PRINCE2, de acordo com OGC (2009), é uma abordagem baseada em 
processos para o gerenciamento de projetos, fornecendo um método “cus- 
tomizável” e “escalável” para o gerenciamento de todos os tipos de projetos. 

A versão atual foi evoluída e apresenta as seguintes mudanças em relação à 
versão de 2005: 

□ Na versão de 2009, a PRINCE2 apresenta dois livros em vez de um: 
Managing Successful Projects Using PRINCE2 e Directing Successful 
Projects Using PRINCE2. Este novo manual é dirigido para executivos 
de Comitês de Projetos. 

□ O modelo de processos da metodologia também foi aperfeiçoado. 

□ Capítulos foram introduzidos para explicar os princípios da metodo¬ 
logia e como “customizá-la” para o ambiente específico do projeto. 

□ Capítulos sobre componentes e técnicas foram removidos, combina¬ 
dos na nova seção denominada “temas”. 

□ Foi reduzido o número de processos e subprocessos. Estes foram re¬ 
movidos completamente e agora são chamados de “atividades”. 

A Figura 9.6 apresenta o novo modelo de processos da metodologia. 
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Figura 9.6 - Processos e atividades do PRINCE2 
Adaptado de OGC (2009) 
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9.5.3.1 Os processos da metodologia 


Dirigindo um projeto (DP - Directing aproject) 


Este processo ocorre desde o início do projeto até o seu encerramento, 
sendo de responsabilidade do Comitê do Projeto. Este Comitê gerencia 
e monitora, através de relatórios e controles, vários pontos de decisão e 
abrange: 

□ Iniciação. 

□ Limites dos estágios (comprometimento de recursos após verificar 
resultados). 

□ Monitoração do projeto, fornecimento de conselhos e orientação e 
reação a condições de exceção. 

□ Encerramento do projeto. 

Este processo não trata das atividades do dia a dia. 


Ins 


talando um projeto (SU- Starting up a project) 


É o primeiro processo da PRINCE2. É um processo de pré-projeto, pro¬ 
jetado para assegurar que os requisitos para a iniciação do projeto estejam 
estabelecidos. O processo trata de três elementos: 

□ Assegurar que a informação requerida pela equipe do projeto esteja 
disponível. 

□ Designar a equipe de gerenciamento do projeto. 

□ Criar o plano do estágio de iniciação. 

Espera-se que exista um termo ou documento equivalente que diga o mo¬ 
tivo do projeto e os resultados esperados. 
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Iniciando um projeto (IP - Initiating aproject) 


Os objetivos deste processo sáo: 

□ Ter acordo sobre se há ou não justificativa suficiente para seguir com 
o projeto. 

□ Estabelecer uma base gerencial estável sobre a qual seguir com o projeto. 

□ Documentar e aceitar que existe um Business Case aceitável para o projeto. 

□ Assegurar uma firme e aceita fimdaçáo para o projeto antes de come¬ 
çar o trabalho. 

□ Obter acordo sobre o compromisso com recursos para a primeira fase 
do projeto. 

□ Permitir e encorajar que o Comitê do Projeto assuma a propriedade 
do projeto. 

□ Assegurar que os investimentos a serem feitos no projeto levem em 
consideração os seus riscos. 


Gerenciando os limites de um estágio (SB - Managing Stage Boundaries) 


Os objetivos deste processo sáo: 

□ Assegurar, para o Comitê do Projeto, que os produtos planejados do 
Plano de Estágio atual foram completados. 

□ Prover informação para o Comitê do Projeto para que este avalie con¬ 
tinuamente a viabilidade do projeto. 

□ Prover para o Comitê do Projeto informações necessárias para que apro¬ 
ve o estágio atual do projeto e que autorize o início do estágio seguinte. 

□ Registrar medições e lições aprendidas que possam ajudar estágios 
posteriores do projeto ou outros projetos. 


Controlando um estágio (CS - Controlling a Stage) 


O objetivo deste processo é assegurar que cada estágio seja desempenhado 
conforme o Plano do Estágio. Este processo compreende atividades como: 











Modelos para Gerenciamento de Projetos 381 


□ Autorização para execução do trabalho planejado. 

□ Obtenção de informação sobre o progresso do projeto. 

□ Análise de mudanças. 

□ Revisão da situação. 

□ Comunicação acerca do projeto. 

□ Tomada de ações corretivas em função de desvios. 


Gerenciando a entrega do produto (MP - Managingproduct delivery ) 


O objetivo deste processo é assegurar que os produtos previstos pelo proje¬ 
to sejam produzidos e entregues, considerando: 

□ Obter a certeza de que o trabalho dos produtos alocados à equipe está 
efetivamente autorizado. 

□ Assegurar o compromisso da equipe do projeto com o resultado esperado. 

□ Avaliar o progresso do projeto. 

□ Assegurar que os produtos atendam às suas respectivas especificações 
de qualidade. 

□ Obter a homologação ou aprovação dos produtos completados. 


Encerrando um projeto (CP - Closing a project) 


O propósito deste processo é executar um encerramento controlado do 
projeto. Seus objetivos são: 

□ Verificar se os objetivos pretendidos foram atendidos. 

□ Verificar se todos os produtos esperados foram entregues e satisfize¬ 
ram as necessidades dos clientes. 

□ Obter a aceitação formal dos produtos. 

□ Assegurar que os produtos resultados foram aceitos e transferidos 
para o cliente. 

□ Confirmar que os arranjos de manutenção e operação estão estabelecidos 
(quando for o caso), visando receber os produtos gerados pelo projeto. 

□ Realizar recomendações para ações de acompanhamento. 
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□ Capturar lições aprendidas e fazer o seu registro. 

□ Preparar um relatório de encerramento do projeto. 

□ Comunicar à organização patrocinadora que os recursos serão 
desmobilizados. 


Planejamento (PL - Planning ) 


Para a PRINCE2, o processo de planejamento se repete e tem um papel 
importante em outros processos. As atividades de planejamento são: 

□ Elaborar o plano. 

□ Definir e analisar os produtos. 

□ Identificar e analisar as atividades e dependências. 

□ Preparar estimativas. 

□ Preparar o cronograma. 

□ Analisar os riscos. 

□ Documentar o plano. 

O manual da PRINCE2 pode ser adquirido diretamente do The Sta- 
tionery Office pelo site www.tsoshop.co.uk ou no site oficial da PRINCE2 
(www.prince-officialsite.com) . 


9 . 5.4 Aplicabilidade do modelo 

A PRINCE2 é, de fato, uma metodologia de gerenciamento de projetos, 
ao contrário do PMBOK, que é um conjunto de conhecimentos. 

A PRINCE2 se aplica a qualquer tipo de projeto, incluindo os projetos de 
tecnologia da informação. 

Com sua característica “customizável”, pode ser facilmente adaptada para 
qualquer tipo de organização. 

Entretanto, da mesma forma que os demais padrões, a sua implementação 
depende da prontidão da organização para a mudança. 






Modelos para Gerenciamento de Projetos 383 


9 . 5.5 Benefícios do modelo 

Os benefícios apregoados pela metodologia sáo: 

□ Ganhar consistência sobre a forma como os projetos são avaliados, 
comissionados, comunicados e revistos. 

□ Padronização da gestão de projetos em toda a organização. 

□ Melhoria na reputação da organização que emprega a metodologia 
perante os seus clientes. 

□ Melhoria da capacidade das equipes de projetos em seu gerenciamento. 

□ Melhoria na alocação dos recursos e na gestão da demanda de proje¬ 
tos e seu impacto na capacidade das equipes de projeto. 

□ Auxilia no aumento da maturidade da organização em gerenciamen¬ 
to de projetos. 


9 . 5.6 Certificações relacionadas 

Da mesma forma que o PMI, a PRINCE2 também mantém certificações 
profissionais. São elas: 

□ Certificação PRINCE2 Foundation , destinada a membros de equipe 
de projetos que necessitam conhecer a terminologia, os princípios e 
os conceitos da metodologia. 

□ Certificação PRINCE2 Practitioner , destinada a profissionais 
gerentes de projeto que necessitam aplicar a metodologia no seu 
trabalho. 

□ Certificação PRINCE2 Professional, destinada a profissionais que 
desejam demonstrar maior experiência na metodologia. Este exame 
testa a habilidade do profissional para gerenciar um projeto PRINCE2 
de média complexidade considerando todos os aspectos do ciclo de 
vida do projeto. 

As empresas inglesas que usam a PRINCE2 podem requerer este reconhe¬ 
cimento por parte do seu governo para ser habilitada a participar de contra¬ 
tações governamentais. 
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9.6 Scrum 

9 . 6.1 Histórico do modelo 

Em 1986, os pesquisadores Hirotaka Takeuchi e Ikujiro Nonaka no¬ 
taram, ao pesquisar empresas de fabricação de automóveis e produtos de 
consumo, que projetos que utilizavam equipes pequenas e multidisciplina- 
res geravam melhores resultados e conceberam um estilo de gerenciamento 
de projetos (publicado no artigo The New Product Development Game — 
Harvard Business Review - Jan/Fev 1986) que envolvia a sobreposição de 
fases no processo e o trabalho conjunto de uma equipe ao longo das várias 
fases do projeto. 

Em 1990, Peter DeGrace e Leslie Hulet Stahl fizeram menção a essa abor¬ 
dagem no livro “Wicked Problems, Righteous Solutions — A Catalogue of 
Modern Software Engineering Paradigms” e a associaram pela primeira vez 
ao nome Scrum 93 . 

No início da década de 90, a metodologia Scrum foi concebida e imple¬ 
mentada em algumas companhias pelos profissionais Ken Schwaber, Jeff Su- 
therland, John Scumniotales e Jeff McKenna, incorporando características do 
estilo de gerenciamento criado por Takeuchi e Nonaka. 

Em 1995, Ken Schwaber e Jeff Sutherland formalizaram a definição 
do Scrum e o apresentaram na Conferência da OOPSLA ( Object-Oriented 
Programming, Systems, Languages and Applications'), iniciando a sua difu¬ 
são na comunidade acadêmica de desenvolvimento de software em todo o 
mundo. 

Em 2001, com a publicação do livro “Agile Software Development 
with Scrum”, Ken Schwaber e Mike Beedle estenderam o modelo e seus 
conceitos para a comunidade de desenvolvedores de software em âmbito 
comercial. 

Inicialmente, o Scrum foi idealizado com um foco acentuado na entrega 
de projetos de desenvolvimento de software em ambientes complexos. Entre¬ 
tanto, tem sido cada vez mais aplicado em projetos de desenvolvimento de 
produtos de outras naturezas. 


93 Scrum é o nome dado a uma formação no jogo de rúgbi, baseada no engajamento de ambos os 
times, que consiste em uma das formas de reiniciar o jogo após a ocorrência de uma infração. 
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9.6.2 Objetivos do modelo 

O Scrum consiste em um método iterativo e incremental para o ge¬ 
renciamento de projetos complexos, cujo objetivo é garantir agilidade nas 
entregas e maximizar a aderência aos requisitos dos clientes, a cooperação 
entre os integrantes da equipe e a produtividade de cada participante. É 
um dos métodos denominados “ágeis” mais difundidos hoje no mercado 
de TI. 

Segundo Schwaber (2004), situações de projetos complexos ocorrem 
quando a complexidade das atividades intermediárias náo permite que seja 
criado um processo definido controlado, que consiga gerar repetitivamente 
produtos em níveis aceitáveis de qualidade. A complexidade de um projeto 
é diretamente proporcional à complexidade dos requisitos dos clientes e da 
tecnologia envolvida, além de ser bastante dependente das características de 
cada membro da equipe (dada a diversidade de habilidades, conhecimentos, 
atitudes etc. que pode ser encontrada em qualquer grupo de pessoas). 

Em situações como essa, Schwaber recomenda ainda a utilização do con¬ 
ceito de controle empírico de processos , que utiliza mecanismos como auto- 
-organização e senso de urgência, e tem os seguintes pilares principais: 

□ Visibilidade: todos os aspectos que afetam os resultados almejados 
devem ser visíveis para os processos de controle (pode também ser 
entendido por “transparência”). 

□ Inspeção: os vários aspectos do processo devem passar por inspeções 
frequentes, visando detectar variações inaceitáveis. 

□ Adaptação: o processo ou os seus produtos intermediários devem ser 
ajustados após a inspeção para minimizar futuros desvios mais se¬ 
veros, caso suas características e resultados estejam fora dos limites 
aceitáveis e coloquem em risco a aceitação do produto final. 


9.6.3 Estrutura do modelo 

O Scrum está estruturado em um conjunto de práticas conduzidas por 
equipes em papéis específicos, organizadas em um fluxo de atividades/eventos 
de duração fixa totalmente controlado, com artefatos e regras bem definidos, 
que visa a obtenção de produtos utilizáveis em intervalos curtos de tempo. 
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9.6.3.1 A base do Scrum 

Todas as práticas do Scrum estão baseadas em um “esqueleto” representado 
por iterações sucessivas de atividades de desenvolvimento (cada uma delas 
gerando um incremento de produto), inspecionadas e ajustadas diariamente 
por membros da própria equipe de trabalho, e orientadas por uma lista de 
requisitos inicial, conforme mostra a Figura 9.7. 



Figura 9.7 - 0 “esqueleto” do Scrum 
Adaptado de Schwaber (2004) 


No começo de cada iteração, a equipe revisa o que deve ser feito e determi¬ 
na o que seria um incremento de funcionalidade viável para ser entregue no 
final da iteração. A equipe é liberada para empregar o seu melhor esforço no 
restante da iteração e apresenta no final o produto final construído. 


9.6.3.2 Os papéis envolvidos no Scrum 

Em um projeto Scrum, todas as responsabilidades estão divididas entre três 
papéis: 


□ Product Owner: pessoa responsável por gerenciar o Backlog do Pro¬ 
duto (garantindo que esteja visível para todos), gerar e disseminar os 














Modelos para Gerenciamento de Projetos 387 


requisitos do projeto, assim como o plano para as entregas sucessivas, 
priorizando os resultados que trarão maior valor agregado ao projeto. 

□ Scrum Master: responsável por implementar o método Scrum, assim 
como por ensiná-lo a todos os envolvidos nos projetos e assegurar que 
todos sigam as suas regras e práticas. 

□ Time Scrum: grupo de desenvolvedores coletivamente responsável 
pelo sucesso de cada iteraçáo e do projeto como um todo, deve ser 
composto por pessoas multidisciplinares e com capacidade de auto- 
-organizaçáo e autogestão. 


9.6.3.3 O fluxo do Scrum 

O processo preconizado pelo Scrum abrange os seguintes elementos (con¬ 
forme ilustrado na Figura 9.8): 



Figura 9.8 - 0 fluxo do Scrum 
Adaptado de Schwaber (2004) 
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□ Visão: deve ser elaborada pelo Product Owner , incluindo o plano de 
releases e os marcos de entregas de produtos a cada Sprint , de forma a 
maximizar o retorno sobre o investimento do projeto de desenvolvi¬ 
mento do produto. 

□ Backlog do Produto: também elaborado pelo Product Owner , contém 
uma lista dos requisitos funcionais e não funcionais do produto, prio- 
rizados e divididos em releases {Sprints). 

□ Reunião de Planejamento da Sprint : o projeto é dividido em Sprints 
com duração de trinta dias corridos cada, a serem executadas uma 
após a outra, sem interrupção. O planejamento é feito em uma reu¬ 
nião com a participação do Time Scrum e pelo Product Owner , em 
dois períodos de quatro horas cada: 

A Nas primeiras quatro horas, é definido o escopo (“o quê”) a ser 
tratado pela Sprint , por meio da seleção dos requisitos do Backlog 
do Produto que serão colocados no Backlog da Sprint. 

A Nas quatro horas finais, ocorre o planejamento propriamente 
dito das tarefas a serem executadas na Sprint (“como”) e o início 
oficial da Sprint, momento em que começa a correr o prazo de 
trinta dias. 

□ Sprint a própria iteração de desenvolvimento do produto, que possui 
duração fixa. Uma Sprint compreende também as suas reuniões de 
planejamento, revisão e retrospectiva. 

□ Scrum Diário: reunião diária de quinze minutos, onde cada membro 
da equipe responde às seguintes questões: 

A O que fiz no projeto desde o último Scrum Diário? 

A O que estou planejando fazer até o próximo Scrum Diário? 

A Existe alguma restrição ou impedimento para que eu honre meus 
compromissos da Sprint atual e/ou do projeto? 

A Além disso, a equipe sincroniza as atividades de todos e programa 
reuniões necessárias para a continuação do projeto. 

□ Reunião de Revisão da Sprint : em quatro horas, o Time Scrum apre¬ 
senta para o Product Owner (e os demais stakeholders ) o resultado do 
trabalho gerado na Sprint e determina junto a eles o que deve fazer 
na próxima Sprint. 
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□ Reunião de Retrospectiva da Sprint em três horas, o Scrum Mas- 
ter estimula os membros do Time Scrum a revisarem o seu proces¬ 
so de desenvolvimento à luz das práticas e do modelo de processo 
do Scrum, visando torná-lo mais eficaz e gratificante para a próxima 
Sprint. 

Ainda de acordo com Schwaber (2004), as reuniões de planejamento da 
Sprint, o Scrum Diário, a revisáo e a retrospectiva da Sprint constituem, jun¬ 
tas, as práticas empíricas de inspeçáo e adaptação do Scrum. 


9.6.3.4 Os artefatos do Scrum 

Existem duas categorias de artefatos no contexto do Scrum: as tabelas de 
Backlog e os gráficos que mostram o trabalho que ainda falta até o final (de¬ 
nominadas Burndown Cbarts). 

As tabelas de Backlog sáo: 

□ Backlog do Produto: consiste em um documento “vivo” elaborado e 
mantido pelo Product Owner que, por definição, nunca está comple¬ 
to (uma vez que sempre existem melhorias a serem implementadas 
em um produto, até que este seja finalmente retirado de circulação). 
Contém uma lista de tudo o que constitui as mudanças que serão 
realizadas no produto para suas futuras versões (características, fun¬ 
ções, tecnologias, adaptações, melhorias, correções etc.). Tais requisi¬ 
tos são ordenados por prioridade e detalhados em termos de atributos 
de descrição, fatores de complexidade/ajuste e estimativas (de esforço 
e prazo) ao longo das futuras Sprints. 

□ Backlog da Sprint: define as tarefas que o Time Scrum deve execu¬ 
tar para criar os incrementos do produto (oriundos do Backlog do 
Produto) durante a execução de uma Sprint. O seu detalhamento 
deve ser suficiente para que possa ser acompanhado nas reuniões do 
Scrum Diário, em tarefas que duram entre quatro e dezesseis horas. 
Cada tarefa deve ser documentada, pelo menos, em termos do seu 
responsável, do seu status (não iniciado, em andamento, finalizada) 
e da quantidade de horas de trabalho restantes a cada dia da Sprint. 
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Os Burndown Charts mostram, graficamente, a quantidade de trabalho 
estimado (esforços restantes) ao longo do tempo, refletindo a sua correlação 
com o progresso das equipes do projeto em reduzir o seu trabalho. Podem ser 
utilizados no contexto do Backlog do Produto (incluindo todas as Sprints) ou 
dentro de cada uma das Sprints (Burndown da Sprint). 


9.6.4 Aplicabilidade do modelo 

O Scrum foi originalmente criado para utilização em projetos de software 
em ambientes complexos (onde os requisitos mudam com alguma frequên¬ 
cia), que possam ter o seu escopo (ou a sua estrutura analítica de projeto - 
EAP ou WBS) organizado e estruturado em pacotes de artefatos incrementais, 
consistentes e utilizáveis, a serem entregues ao cliente em períodos sucessivos 
de quinze a trinta dias cada. 

A princípio, esse conceito é potencialmente aplicável a qualquer projeto 
ou programa cujo objetivo seja o desenvolvimento de produtos ou serviços de 
outra natureza, ou mesmo que envolvam iniciativas de melhoria por meio da 
utilização de metodologias como Lean, Seis Sigma etc. Em suma, o Scrum é 
uma abordagem recomendada (e tem demonstrado forte aplicabilidade) para 
projetos que exigem a combinação focada das habilidades e dos conhecimen¬ 
tos de um time e que envolvam esforços colaborativos intensos. 

Segundo Pries & Quigley (2010), existem maneiras de adaptar o Scrum 
para aplicação em vários tipos de programas e projetos complexos, tais como: 

□ Combinando com métodos tradicionais de gerenciamento de pro¬ 

jetos: pode-se relacionar conceitos e artefatos, tais como EAP (Es¬ 
trutura Analítica do Projeto) e Backlog do Produto, Análise de Valor 
Agregado, os Burndown Charts e o Plano de Comunicação, às reu¬ 
niões de controle das Sprints (planejamento, diária, revisão, retros¬ 
pectiva) etc. 

□ Gerenciamento de programas complexos: adoção de uma estrutura 
de “Scrum de Scrums”, onde o Backlog de Produto pode ser decom¬ 
posto em sub-backlogs, cada um sendo consumido pelo seu respectivo 
Time Scrum. 

□ Atuação em áreas funcionais que atendem a vários projetos (por 

exemplo, equipes de teste ou garantia de qualidade) : no Backlog de 
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Produto, podem entrar tarefas dos vários projetos e no Backlog de 
cada Sprint, aquelas tarefas que couberem no prazo de trinta dias. 

□ Combinando com uma metodologia no formato “cascata” : pode- 
-se dividir o cronograma em módulos de duração fixa, de forma a 
sincronizar, por exemplo, uma sequência de Sprints com um marco 
(milestone ) previsto no projeto, assim como realizar as atividades de 
verificação e validação de forma evolutiva em cada Sprint. 

□ Combinando com a abordagem Seis Sigma: pode-se encapsu¬ 
lar cada uma das fases da metodologia DMAIC ( Define, Measu- 
re, Analyze, Improve, Control) em uma Sprint, executando-as uma 
após a outra. 

Schwaber (2004) menciona a possibilidade de utilização do Scrum em um 
contexto de contrato com preço e duração prefixados. Nesses casos, o Backlog 
do Produto pode ser utilizado não somente para demonstrar ao cliente que 
os requisitos foram compreendidos, mas também que a prioridade de cada 
um para a geração de valor foi compreendida. Os requisitos mais relevantes 
podem ser selecionados para as primeiras Sprints e os incrementos na funcio¬ 
nalidade, mensurados a cada reunião de acompanhamento. 

De qualquer forma, é importante ter em mente que a adoção do Scrum 
por uma organização deve ser feita de forma criteriosa e que há uma série de 
desafios a serem enfrentados (que poderão colocar em risco a eficácia do mé¬ 
todo), tais como: 

□ É fundamental ter uma equipe que funcione bem trabalhando em 
grupo, uma vez que o sucesso do trabalho depende de um esforço 
intensivo nas habilidades que cada um tem como diferencial. 

□ E importante que cada membro dos Times Scrum tenha um forte 
senso de autogestão. 

□ Deve-se garantir que os integrantes da equipe estejam alocados 
a somente um projeto (ou seja, ao cumprimento de somente um 
Backlog). 

□ Deve-se garantir o comprometimento de todos os envolvidos (princi¬ 
palmente por parte daqueles que representam o cliente). 

□ Deve-se assegurar que os Backlogs estejam bem documentados, de 
forma que não haja mal-entendidos entre os envolvidos. 
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□ Pode haver algumas dificuldades para “atomizar” as tarefas a serem 
colocadas em cada linha dos Backlogs, assim como para estabelecer as 
dependências entre elas, o que poderá prejudicar o planejamento e o 
bom andamento na execução das Sprints. 

□ Deve-se garantir que todas as reuniões (planejamento, diária, revisáo, 
retrospectiva) das Sprints sejam realizadas e que os tempos fixos sejam 
efetivamente cumpridos, sob risco de prejudicar o senso de discipli¬ 
na, que é crucial para o sucesso do método. 


9.6.5 Benefícios do modelo 

A adoçáo de métodos ágeis como o Scrum para projetos de software tem 
trazido para as organizações de TI benefícios relacionados à melhoria da ca¬ 
pacidade de gestáo, assim como à obtençáo de vantagens competitivas em 
relaçáo a outras organizações. Entre esses benefícios, podemos enumerar: 

□ Maior agilidade no controle e no gerenciamento do andamento dos 
trabalhos. 

□ A ênfase no trabalho em equipe e o foco em resultados rápidos propiciam 
um maior senso de cooperação e de responsabilidade compartilhada. 

□ Equipes mais motivadas e com autoestima constantemente renovada. 

□ Plano de comunicação mais efetivo, devido às reuniões e comunica¬ 
ções constantes entre os membros do Time Scrum (consequentemen¬ 
te, usuários mais informados durante e após as Sprints). 

□ A evolução do projeto e os eventuais riscos e impedimentos têm 
maior visibilidade no momento em que acontecem. 

□ Maior assertividade no atendimento aos requisitos dos clientes (devi¬ 
do à sincronização com protótipos iterativos). 

□ Melhoria da produtividade das equipes, uma vez que tarefas que não 
agregam valor ao resultado tendem a ser eliminadas do trabalho. 

□ Redução do overhead da organização (as equipes são autogerenciadas 
e estão integralmente envolvidas em projetos). 

□ Maior qualidade dos produtos, devido à maior probabilidade de de¬ 
tecção antecipada de defeitos. 

□ Detecção antecipada de obstáculos que possam comprometer o de¬ 
senvolvimento e a entrega dos produtos. 
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□ Possibilidade de responder mais rapidamente a mudanças nos requi¬ 
sitos (podem ser incluídas em Sprints posteriores). 

□ Visibilidade antecipada do Retorno sobre o Investimento dos proje¬ 
tos, devido à priorizaçáo dos requisitos mais relevantes e às entregas 
em prazos mais curtos e constantes. 


9.6.6 Certificações relacionadas 

A Scrum Alliancê )A oferece um programa de certificação em vários níveis, 
baseado em cursos especializados com exames integrados: 

□ CSM — Certified Scrum Master . destinado a pessoas que trabalham em 
um Time Scrum, possui ênfase acentuada no papel do Scrum Master 
e na demonstração do entendimento da terminologia, das práticas e 
dos princípios do Scrum. 

□ CSPO — Certified Scrum Product Owner . possui ênfase acentuada no 
papel de Product Owner (representante do cliente), focando aspectos 
como gestão de stakebolders , retorno sobre investimento, formatação 
de backlogs , critérios de aceite etc.). 

□ CSD — Certified Scrum Developer . destinado àqueles que possuem um 
entendimento prático dos princípios do Scrum e que tenham assi¬ 
milado habilidades especializadas de engenharia com métodos ágeis. 

□ CSP - Certified Scrum Professional . nível superior de expertise para 
aqueles que já possuem uma certificação CSM, CSPO ou CSD. 

□ CST — Certified Scrum Trainer . destinado àqueles que desejam se li¬ 
cenciar como treinadores oficiais dos cursos preparatórios para as cer¬ 
tificações Scrum. 

□ CSC — Certified Scrum Coack . destinado aos especialistas no Scrum, 
tanto em teoria quanto na prática. Um Coach deve possuir um conhe¬ 
cimento profundo das práticas e princípios do Scrum e experiência 
real na sua utilização em projetos, podendo atuar como um “mentor” 
para os Scrum Masters e Times Scrum em diversas situações onde 
estiverem precisando de orientação ou enfrentando desafios acima do 
grau atual de maturidade da equipe. 


94 Maiores informações no site http://www.scrumalliance.org. 
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Modelos para Segurança 
da Informação - ISO/IEC 27001 
e 27002 


10.1 Histórico do modelo 

A origem de praticamente todas as normas internacionais relativas à segu¬ 
rança da informação é o Governo Britânico. 

A Britisb Standard (BS) 7799, que deu origem à ISO 17799 e agora foi 
substituída pela ISO/IEC 27002, nasceu no Commercial Computer Security 
Centre (CCSC) do Department ofTrade and Industry. O CCSC foi criado con¬ 
siderando duas frentes de atuação: a primeira era apoiar fornecedores de pro¬ 
dutos de segurança em TI a partir de um conjunto de critérios de avaliação e 
um esquema de certificação, e a segunda era auxiliar os usuários de TI através 
de um “Código de Prática do Usuário”. Este código foi publicado em 1989. 

O código foi aperfeiçoado posteriormente pela comunidade britânica de 
TI, o que resultou no “Código de prática para a gestão da segurança da infor¬ 
mação”. Esse código deu origem em 1995 à BS 7799:1995, parte 1. 

Em abril de 1999, foi publicada a primeira revisão da BS 7799 Parte 1 
(BS7799T999). Em outubro de 1999 esta norma foi proposta como norma 
ISO, dando origem, em dezembro de 2000, à ISO/IEC 17799:2000. 

A parte 1 da BS 7799 era somente um código de prática e não permitia a 
certificação de um sistema gerencial de segurança da informação, conforme um 
esquema de certificação de reconhecimento mútuo em âmbito internacional. 
Para suprir essa necessidade, em 5 de setembro de 2002 foi lançada a parte 2 da 
BS 7799 (BS 7799-2:2002). Essa norma está em harmonia com a ISO 9000 
e a ISO 14000 (esta última trata de sistemas de gerenciamento ambientais) e 
tem por objetivo a implantação de um ISMS ou Information Security Manage¬ 
ment System, considerando controles selecionados a partir da ISO/IEC 17799. 
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Da mesma forma como ocorreu com a 17799, a BS 7799-2:2002 
transformou-se na ISO/IEC 27001:2005, publicada em 15 de outubro 
de 2005. 

A ISO C International Organization for Standardization ) e o IEC ( Interna¬ 
tional Eletrotechnical Comissiori) estão prevendo o lançamento de várias nor¬ 
mas relativas à série 27000 sobre segurança da informação. 

Atualmente, a série 27000 já contempla as seguintes normas: 

□ ISO/IEC 27000:2012 - Information tecbnology — Security tech- 
niques — Information security management systems — OverView and 
vocabulary. 

□ ISO/IEC 27001:2013 - Information tecbnology — Security tecbniques 

- Information security management systems — Requirements. 

□ ISO/IEC 27002:2013 - Information tecbnology — Security tecbniques 
— Code ofpractice for Information security Controls. 

□ ISO/IEC 27003:2010 - Information tecbnology - Security tecb¬ 
niques — Information security management system implementation 
guidance. 

□ ISO/IEC 27004:2009 - Information tecbnology — Security tecbniques 

- Information security management — Measurement. 

□ ISO/IEC 27005:2011 - Information tecbnology — Security tecbniques 
— Information security risk management. 

□ ISO/IEC 27006:2011 - Information tecbnology — Security tecbniques 

- Requirements for bodies providing audit and certification ofinforma- 
tion security management systems. 

□ ISO/IEC 27007:2011 - Information tecbnology — Security tecbniques 
— Guidelines for Information security management systems auditing. 


10.2 Objetivos do modelo 

□ A ISO/IEC 27001 foi preparada para prover requisitos para estabele¬ 
cer, implementar, manter e melhorar continuamente um sistema de 
gestão de segurança da informação (SGSI). Vide ABNT (2013). 

□ A ISO/IEC 27002 é projetada para organizações que usam a norma 
como uma referência para selecionar controles dentro do processo de 
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implementação do sistema de gestão de segurança da informação ou 
como um guia para implementar controles aceitos de segurança da 
informação. Vide ISO (2013). 


10.3 Estrutura do modelo 

10.3.1 ISO/IEC 27001 

A versão 2013 desta norma aplica a estrutura de alto nível, os títulos 
de subseções, textos, termos comuns e definições básicas, apresentadas no 
anexo SL da ISO/IEC Directives, Part 1, Consolidated ISO Supplement , 
mantendo dessa forma compatibilidade com outras normas de sistemas de 
gestão. 

Essa abordagem é útil para as organizações que escolhem operar um único 
sistema de gestão que atenda aos requisitos de duas ou mais normas de siste¬ 
mas de gestão, como a ISO 9000, a ISO 14000 etc. 

Seguindo os conceitos de sistemas de gestão, a norma preconiza: 

□ Que o contexto do sistema de gestão de segurança da informação seja 
compreendido, inclusive a determinação do seu escopo. 

□ A liderança necessária para a implementação do sistema de gestão 
de segurança da informação, considerando o comprometimento da 
administração, a existência de uma política e a autoridade, responsa¬ 
bilidades e papéis organizacionais. 

□ O planejamento do sistema de gestão da segurança da informação, 
compreendendo ações para contemplar riscos e oportunidades, a de¬ 
terminação dos objetivos do sistema. 

□ O apoio necessário para o sistema em termos de recursos, competên¬ 
cias, conscientização, a comunicação e a informação documentada. 

□ A operação do sistema, considerando o planejamento operacional, 
a avaliação dos riscos de segurança da informação, o tratamento dos 
riscos. 

□ A avaliação do desempenho do sistema, contemplando monitora¬ 
mento, medição e análise e avaliação, a auditoria interna e a análise 
crítica pela direção. 
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□ Por fim, a melhoria do sistema, contemplando o tratamento de não 
conformidades e ações corretivas, e a melhoria contínua. 


10.3.1.1 O sistema de gestão da segurança da informação 


A determinação do escopo do sistema 


A norma diz que a organização deve: 

□ Entender o contexto interno e externo da organização em relação aos 
riscos, identificando as questões que são relevantes para o seu propósito. 

□ Identificar as partes interessadas que são relevantes para o sistema. 

□ Identificar os requisitos dessas partes interessadas. 

□ A definição do escopo do sistema face às questões internas, externas 
e requisitos. 

□ O escopo deve ser documentado. 


A liderança do sistema 


A alta administração deve demonstrar liderança e comprometimento em 
relação ao sistema de gestão da segurança da informação evidenciando o 
seguinte: 

□ Uma política de segurança da informação. 

□ A garantia de que os requisitos do sistema estejam integrados com os 
processos da organização. 

□ Que há recursos suficientes para a implantação e operação do sistema. 

□ Comunicação da importância do sistema para a organização. 

□ Melhoria contínua. 

□ Autoridades, responsabilidades e papéis organizacionais relativos à se¬ 
gurança da informação estejam definidos e comunicados. 







398 Implantando a Governança de TI - 4 a edição 


O planejamento do sistema 


A organização deve: 

□ Determinar os riscos e as oportunidades que necessitam ser conside¬ 
rados pelo sistema. 

□ Aplicar um processo de avaliação de riscos de segurança da informa¬ 
ção, com critérios de aceitação de riscos, avaliações contínuas, identi¬ 
ficação dos riscos, dos responsáveis e análise qualitativa e quantitativa. 

□ Tratar os riscos, elaborando um plano com opções de tratamento, ob¬ 
ter aprovação pelos responsáveis pelos riscos, determinar os controles 
que são necessários. 

□ Estabelecer os objetivos de segurança da informação para as funções 
e níveis relevantes. 

□ Elaborar um plano de segurança da informação contendo o que será 
feito, quais recursos serão necessários, as responsabilidades, os prazos 
e marcos de controle e como os resultados serão avaliados. 


Estabelecendo o apoio ao sistema 


A organização deve: 

□ Determinar e prover os recursos necessários para o sistema. 

□ Determinar as competências necessárias das pessoas que afetam o de¬ 
sempenho do sistema. 

□ Treinar as pessoas. 

□ Conscientizar as pessoas sobre a política, sua contribuição para a efi¬ 
cácia do sistema, implicações de não conformidades. 

□ Determinar as comunicações internas e externas relevantes para o 
sistema em termos do que comunicar, quando comunicar, a quem 
comunicar e o processo de comunicação. 

□ Documentar a informação sobre o sistema, considerando a criação, a 
atualização e o controle da informação documentada. 
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A operação do sistema 


A organização deve: 

□ Planejar operacionalmente o sistema, implementando os pro¬ 
cessos necessários para atender aos requisitos de segurança da 
informação. 

□ Controlar os processos terceirizados. 

□ Controlar as mudanças no sistema. 

□ Executar as avaliações de riscos. 

□ Tratar os riscos. 


A avaliação do desempenho do sistema 


A organização deve: 

□ Monitorar, medir, analisar e avaliar o sistema. 

□ Manter um programa de auditoria. 

□ Executar auditorias internas sobre o sistema. 

□ Avaliar criticamente o sistema pela direção. 


A melhoria do sistema 


A organização deve: 

□ Corrigir não conformidades. 

□ Eliminar causas de não conformidades. 

□ Avaliar eficácia do tratamento das não conformidades. 

□ Realizar mudanças no sistema. 

□ Melhorar continuamente o sistema. 
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10.3.2 ISO/IEC 27002 

Esta norma está estruturada nas seguintes seções: 

□ Política de segurança da informação. 

□ Organização da segurança da informação. 

□ Segurança em recursos humanos. 

□ Gestão de ativos. 

□ Controle de acesso. 

□ Criptografia. 

□ Segurança física e ambiental. 

□ Segurança das operações. 

□ Segurança das comunicações. 

□ Aquisição, desenvolvimento e manutenção de sistemas. 

□ Relacionamentos com fornecedores. 

□ Gestão dos incidentes de segurança da informação. 

□ Aspectos de segurança da informação da gestão da continuidade de 
negócios. 

□ Conformidade. 

Cada uma das cláusulas é constituída por categorias de segurança da in¬ 
formação, sendo que cada categoria tem um objetivo de controle definido, 
um ou mais controles que podem ser aplicados para atender ao objetivo de 
controle, as descrições dos controles, as diretrizes de implementação e infor¬ 
mações adicionais. 

A norma preconiza 114 controles, quais sejam: 


Política de segurança da informação 


□ Um conjunto de políticas para segurança da informação deve ser defi¬ 
nido, aprovado pela administração, publicado e comunicado para os 
empregados e partes externas relevantes. 

□ As políticas de segurança da informação devem ser revistas a inter¬ 
valos planejados ou quando mudanças significativas ocorrerem para 
assegurar sua utilidade contínua, adequação e eficácia. 
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Organização da segurança da informação 


□ Todas as responsabilidades relativas à segurança da informação de¬ 
vem ser definidas e alocadas. 

□ Deveres conflitantes e áreas de responsabilidade devem ser segregadas 
para reduzir oportunidades para a modificação não autorizada e não 
intencional ou o mau uso de ativos. 

□ Contatos apropriados com autoridades relevantes devem ser mantidos. 

□ Contatos apropriados com grupos especiais de interesse ou outros 
fóruns especialistas em segurança e associações de profissionais devem 
ser mantidos. 

□ A segurança da informação deve ser endereçada na gestão de projetos, 
independentemente do tipo de projeto. 

□ Uma política e medidas de suporte à segurança devem ser adotadas 
para gerenciar os riscos introduzidos pelo uso de dispositivos móveis. 

□ Uma política e medidas de suporte à segurança devem ser implemen¬ 
tadas para proteger a informação acessada, processada ou armazenada 
em sites de teletrabalho. 


Segurança em recursos humanos 


□ Deve ser executada a verificação de antecedentes de todos os candi¬ 
datos a emprego, em conformidade com as leis, regulações e ética, 
de forma proporcional aos requisitos do negócio, a classificação da 
informação a ser acessada e o risco percebido. 

□ Os acordos contratuais com empregados e fornecedores devem esta¬ 
belecer suas responsabilidades e da organização sobre a segurança da 
informação. 

□ A administração deve requerer que todos os empregados e fornecedo¬ 
res apliquem a segurança da informação de acordo com as políticas e 
os procedimentos estabelecidos pela organização. 

□ Todos os empregados da organização e, onde relevante, fornecedores, 
devem receber conscientização, educação e treinamento apropriado e 
atualizações periódicas sobre políticas e procedimentos relevantes de 
acordo com a sua função de trabalho. 
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□ Deve haver um processo disciplinar formal e comunicado para tomar 
ação contra empregados que cometeram violações da segurança da 
informação. 

□ Responsabilidades e deveres relativos à segurança da informação que 
se mantêm válidos após o término ou mudança da situação emprega- 
tícia devem ser definidos, comunicados e reforçados junto ao empre¬ 
gado ou fornecedor. 


Gestão de ativos 


□ Ativos associados com informação e instalações de processamento de 
informações devem ser identificados (e um inventário desses ativos 
deve ser elaborado e mantido). 

□ Ativos mantidos no inventário devem ter propriedade. 

□ Regras para o uso aceitável da informação e dos ativos associados com 
a informação e com as instalações de processamento de informações 
devem ser identificadas, documentadas e implementadas. 

□ Todos os empregados e usuários de terceiras partes devem retornar 
todo o ativo organizacional que esteja em sua posse após o término 
de seu emprego, contrato ou acordo. 

□ A informação deve ser classificada em termos dos requisitos legais, 
valor, criticidade e sensibilidade para divulgação ou modificação não 
autorizada. 

□ Um conjunto apropriado de procedimentos para a rotulação da in¬ 
formação deve ser desenvolvido e implementado de acordo com o 
esquema de classificação da informação adotada pela organização. 

□ Procedimentos para o tratamento dos ativos devem ser desenvolvidos 
e implementados de acordo com o esquema de classificação da infor¬ 
mação adotado pela organização. 

□ Procedimentos devem ser implementados para o gerenciamento de 
mídias removíveis, de acordo com o esquema de classificação da in¬ 
formação adotado pela organização. 

□ Mídias devem ser descartadas de forma segura, usando procedimen¬ 
tos formais quando não forem mais necessárias. 

□ Mídias que contêm informação devem ser protegidas contra acesso 
não autorizado, mau uso ou corrupção durante o seu transporte. 
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mtrole de acesso 


□ Uma política de acesso deve ser estabelecida, documentada e revista 
com base nos requisitos do negócio e da segurança da informação. 

□ O acesso à rede e aos serviços de rede fornecidos aos usuários deve ser 
permitido somente àqueles que tenham sido especialmente autoriza¬ 
dos para uso. 

□ Um processo de registro deve ser implementado para permitir a atri¬ 
buição de direitos de acesso. 

□ Um processo formal de provisionamento de acesso ao usuário deve 
ser implementado para atribuir ou revogar direitos de acesso para 
todos os tipos de usuários e para todos os sistemas e serviços. 

□ A alocação e o uso de direitos de privilégios de acesso devem ser res¬ 
tritos e controlados. 

□ A alocação de informação sobre autenticação secreta deve ser contro¬ 
lada através de um processo de gestão formal. 

□ Proprietários de ativos devem rever os direitos de acesso dos usuários 
em intervalos de tempo regulares. 

□ Os direitos de acesso de todos os empregados e de terceiros à infor¬ 
mação e às instalações de processamento de informações devem ser 
removidos logo após o término do emprego, do contrato e do acordo. 

□ Deve ser requerido dos usuários que sigam as práticas organizacionais 
no uso de informação secreta autenticada. 

□ O acesso à informação e às funções de sistemas aplicativos deve ser 
restrito de acordo com a política de controle de acesso. 

□ Quando requerida pela política de controle de acesso, o acesso a sistemas 
e aplicações deve ser controlado por um procedimento seguro de logon. 

□ Sistemas de gerenciamento de senhas devem ser interativos e assegu¬ 
rar a qualidade das senhas. 

□ O uso de programas utilitários que possam ser capazes de sobrescre- 
ver controles de sistemas e aplicações deve ser restrito e estritamente 
controlado. 

□ O acesso ao código-fonte deve ser restrito. 
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Criptografia 


□ Uma política sobre o uso de controles criptográficos para proteger a 
informação deve ser desenvolvida e implementada. 

□ Uma política sobre o uso, proteção e ciclo de vida das chaves cripto¬ 
gráficas deve ser desenvolvida e implementada, considerando todo o 
seu ciclo de vida. 


Segurança física e ambiental 


□ Perímetros de segurança devem ser definidos e usados para proteger 
áreas que contêm tanto informação como instalações de processa¬ 
mento de informações sensíveis e críticas. 

□ Áreas seguras devem ser protegidas por controles de entrada apro¬ 
priados para assegurar que o acesso seja permitido somente ao pessoal 
autorizado. 

□ A segurança física para escritórios, salas e instalações deve ser proje¬ 
tada e aplicada. 

□ A proteção física contra desastres naturais, ataques maliciosos ou aci¬ 
dentes deve ser projetada e aplicada. 

□ Um procedimento para trabalhar em áreas seguras deve ser projetado 
e aplicado. 

□ Pontos de acesso, tais como áreas de entrega e de carregamento e 
outros pontos onde pessoas não autorizadas possam entrar, devem 
ser controlados e, se possível, ser isolados das instalações de processa¬ 
mento de informações para evitar acesso não autorizado. 

□ Equipamentos devem ser instalados e protegidos para reduzir ris¬ 
cos de ameaças ambientais, danos e oportunidades para acesso não 
autorizado. 

□ Equipamentos devem ser protegidos de falhas de energia e de outros 
rompimentos causados por falhas nos serviços de suporte. 

□ Os cabeamentos de energia e de telecomunicações que carregam da¬ 
dos ou serviços de suporte à informação devem ser protegidos da 
interceptaçáo, interferência ou dano. 
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□ Os equipamentos devem ser mantidos corretamente para assegurar 
sua disponibilidade e integridade contínuas. 

□ Equipamentos, informação ou software não devem ser retirados das 
instalações sem autorização prévia. 

□ Segurança deve ser aplicada a ativos usados fora das instalações da or¬ 
ganização, levando em consideração os diferentes riscos de trabalhar 
fora das instalações da organização. 

□ Todos os itens dos equipamentos que contêm mídia de armazena¬ 
mento devem ser verificados para assegurar que qualquer dado sensí¬ 
vel ou licença de software foram removidos ou sobrescritos antes do 
seu descarte ou reuso. 

□ Usuários devem assegurar que equipamentos que não estejam sendo 
usados tenham proteção apropriada. 

□ Uma política de mesa limpa e tela bloqueada deve ser adotada. 


Segurança das operações 


□ Procedimentos de operação devem ser documentados e tornados dis¬ 
poníveis para todos os usuários quando necessitarem. 

□ Mudanças para a organização, processos de negócio, instalações de 
processamento das informações e sistemas que afetam a segurança da 
informação devem ser controlados. 

□ O uso dos recursos deve ser monitorado, sintonizado e a capacidade 
futura requerida deve ser projetada para assegurar o desempenho re¬ 
querido para o sistema. 

□ Ambientes de desenvolvimento, teste e de operação devem ser sepa¬ 
rados para reduzir os riscos de acesso não autorizados ou mudanças 
no ambiente operacional. 

□ Controles de detecção, prevenção e recuperação para proteger contra 
malwares devem ser implementados, combinados com a apropriada 
conscientização dos usuários. 

□ Cópias backup de informação, software e imagens de sistemas devem 
ser feitas e testadas regularmente de acordo com uma política acor¬ 
dada de backup. 
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□ Logs de eventos que registram as atividades dos usuários, exceções, 
faltas e eventos de segurança da informação devem ser produzidos, 
mantidos e revistos regularmente. 

□ Informação sobre logs deve ser protegida contra adulteração e acesso 
não autorizado. 

□ Atividades de administrador de sistemas e operadores devem ser con¬ 
troladas e os logs, protegidos e revistos regularmente. 

□ Os relógios de todos os sistemas relevantes dentro da organização ou 
domínio de segurança devem ser sincronizados a uma única referên¬ 
cia de fonte de tempo. 

□ Procedimentos devem ser implementados para controlar a instalação 
de software e sistemas operacionais. 

□ A informação acerca de vulnerabilidades técnicas dos sistemas de in¬ 
formação em uso deve ser obtida no tempo apropriado e a exposição 
da organização a tais vulnerabilidades, avaliada e medidas apropria¬ 
das devem ser tomadas para tratar os riscos associados. 

□ Regras que governam a instalação de software pelos usuários devem 
ser estabelecidas e implementadas. 

□ Atividades e requisitos de auditoria envolvendo a verificação dos sis¬ 
temas operacionais devem ser cuidadosamente planejados e acorda¬ 
dos para minimizar interrupções nos processos de negócio. 


Segurança das comunicações 


□ As redes devem ser gerenciadas e controladas para proteger a informa¬ 
ção em sistemas e aplicações. 

□ Mecanismos de segurança, níveis de serviços e requisitos de gestão de 
todos os serviços da rede devem ser identificados e incluídos nos acor¬ 
dos de serviços de rede, tanto para serviços fornecidos internamente 
ou por terceiros. 

□ Grupos de serviços de informação, usuários e sistemas de informação 
devem ser segregados nas redes. 

□ Políticas formais de transferência, procedimentos e controles devem 
ser colocados em prática para proteger a transferência de informação 
através do uso de todos os tipos de instalações de comunicação. 
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□ Acordos devem endereçar a segurança da transferência de informação 
do negócio entre a organização e partes externas. 

□ Informações envolvidas em mensagens eletrônicas devem ser apro¬ 
priadamente protegidas. 

□ Requisitos de confidencialidade ou acordos de confidencialidade re¬ 
fletindo as necessidades da organização para a proteção da informa¬ 
ção devem ser identificados, revistos regularmente e documentados. 


Aquisição, desenvolvimento e manutenção de sistemas 


□ Os requisitos de segurança da informação devem ser incluídos nos 
requisitos para novos sistemas de informação ou melhorias em siste¬ 
mas existentes. 

□ Informações envolvidas em serviços de aplicação que passam por re¬ 
des públicas devem ser protegidas de atividades fraudulentas, dispu¬ 
tas contratuais e divulgação e modificação não autorizada. 

□ Informações envolvidas em aplicações de serviços de transação devem 
ser protegidas para prevenir transmissão incompleta, roteamento mal 
executado, alteração não autorizada de mensagem, divulgação não 
autorizada, duplicação não autorizada da mensagem ou retorno. 

□ Regras para o desenvolvimento de software e sistemas devem ser esta¬ 
belecidas e aplicadas para os desenvolvimentos dentro da organização. 

□ Mudanças em sistemas durante o ciclo de desenvolvimento devem ser 
controladas pelo uso de procedimentos formais de controle de mudança. 

□ Quando plataformas operacionais são mudadas, as aplicações críticas 
de negócio devem ser revistas e testadas para assegurar que não há 
impacto adverso nas operações ou segurança organizacional. 

□ Modificações em pacotes de software devem ser desencorajadas, limi¬ 
tadas às mudanças necessárias, e todas as mudanças devem ser estri¬ 
tamente controladas. 

□ Princípios para a engenharia de sistemas seguros devem ser estabele¬ 
cidos, documentados, mantidos e aplicados para qualquer esforço de 
implementação de sistemas. 

□ As organizações devem estabelecer e proteger ambientes seguros para 
o esforço de desenvolvimento e integração que cobre o ciclo de vida 
de desenvolvimento de sistemas. 
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□ A organização deve supervisionar e monitorar as atividades de desen¬ 
volvimento de sistemas terceirizadas. 

□ Testes de funcionalidades de segurança devem ser executados durante 
o desenvolvimento. 

□ Testes e critérios de aceitação de programas devem ser estabelecidos 
para novos sistemas de informação, atualizações e novas versões. 

□ Dados de testes devem ser selecionados cuidadosamente, protegidos 
e controlados. 


Rela* 


cionamento com fornecedores 


□ Requisitos de segurança da informação para a mitigação de riscos 
associados com o acesso do fornecedor aos ativos organizacionais de¬ 
vem ser acordados com o fornecedor e documentados. 

□ Todos os requisitos relevantes de segurança da informação devem ser 
estabelecidos e acordados com cada fornecedor que pode acessar, pro¬ 
cessar, armazenar, comunicar ou fornecer componentes de infraestru- 
tura de TI para as informações da organização. 

□ Acordos com fornecedores devem incluir requisitos para tratar os ris¬ 
cos de segurança da informação associados com os serviços de tec¬ 
nologia da informação e comunicação e com a cadeia de suprimento 
dos produtos. 

□ As organizações devem monitorar, rever e auditar, regularmente, a 
entrega dos serviços pelo fornecedor. 


Gestão dos incidentes de segurança da informação 


□ Responsabilidades e procedimentos gerenciais devem ser estabeleci¬ 
dos para assegurar respostas rápidas, efetivas e ordenadas aos inciden¬ 
tes de segurança da informação. 

□ Eventos de segurança da informação devem ser comunicados através 
de canais gerenciais apropriados o mais rápido possível. 

□ Empregados e fornecedores que usam sistemas de informação e ser¬ 
viços da organização devem ser orientados para anotar e comunicar 
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qualquer fraqueza observada ou suspeita de segurança da informação 
nos sistemas ou serviços. 

□ Eventos de segurança da informação devem avaliados e classificados. 

□ Incidentes de segurança da informação devem ser respondidos de 
acordo com procedimentos documentados. 

□ O conhecimento obtido da análise e da resolução dos incidentes de 
segurança da informação deve ser usado para reduzir a probabilidade 
ou o impacto dos futuros incidentes. 

□ A organização deve definir e aplicar procedimentos para a identifica¬ 
ção, coleta, aquisição e preservação da informação a qual pode servir 
de evidência. 


Aspectos de segurança da informação da gestão da continuidade do 
negócio 


□ A organização deve determinar seus requisitos para a segurança da 
informação e para a continuidade da gestão da segurança da informa¬ 
ção em situações adversas, por exemplo, durante crises ou desastres. 

□ A organização deve estabelecer, documentar, implementar e manter 
processos, procedimentos e controles para assegurar o nível requerido 
de continuidade durante uma situação adversa. 

□ A organização deve verificar periodicamente os controles implemen¬ 
tados de continuidade da segurança da informação visando assegurar 
que estejam válidos e efetivos durante uma situação adversa. 

□ As instalações de processamento de informações devem ser imple¬ 
mentadas com redundância suficiente para atender aos requisitos de 
disponibilidade. 


mformidade 


□ Todos os requisitos relevantes de legislação, regulatórios, contratuais, 
além da abordagem à organização para atender a esses requisitos, de¬ 
vem ser explicitamente identificados, documentados e mantidos atu¬ 
alizados para cada sistema de informação da organização. 
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□ Procedimentos apropriados devem ser implementados para assegurar 
compliance com legislação e requisitos contratuais e regulatórios re¬ 
lacionados com direitos de propriedade intelectual e uso de software 
produtos proprietários. 

□ Registros devem ser protegidos de perda, destruição, falsificação, 
acesso e liberação não autorizada, de acordo com requisitos legais, 
regulatórios, contratuais e de negócio. 

□ A privacidade e a proteção de informação pessoal devem ser assegura¬ 
das como requerido pela legislação e regulações onde aplicável. 

□ Controles criptográficos devem ser usados em conformidade com to¬ 
dos os acordos, legislação e regulações relevantes. 

□ A abordagem da organização para a gestão da segurança da infor¬ 
mação e sua implementação deve ser revista independentemente de 
intervalos de tempo regulares ou quando mudanças significativas 
ocorrerem. 

□ Os gerentes devem rever regularmente a conformidade dos procedi¬ 
mentos e do processamento da informação dentro de sua área de res¬ 
ponsabilidade usando políticas, padrões e quaisquer outros requisitos 
de segurança apropriados. 

□ Os sistemas de informação devem ser revisados regularmente para 
fins de conformidade com políticas e padrões de segurança da infor¬ 
mação da organização. 


10.4 Aplicabilidade do modelo 

Independentemente dos aspectos de certificação, este modelo se aplica a 
qualquer organização cujos negócios dependam fortemente de informação 
eTI. 

Em nossa opinião, a utilização de um modelo nesses moldes para as empre¬ 
sas de serviços de TI (tais como provedores de desenvolvimento de sistemas, 
provedores de serviços de computação em nuvem etc.) é praticamente obriga¬ 
tória, por proporcionar maior garantia de proteção dos ativos de informação 
do cliente, significando garantia da continuidade dos serviços para o cliente. 

Aplica-se também para organizações com fins lucrativos, terceiro setor e 
governamentais que armazenam transações e dados de pessoas e clientes ou 
informações sigilosas. 
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A amplitude da segurança da informação é bem maior do que somente 
TI, abrangendo também, e fortemente, as áreas de negócio, pois são elas que 
definem privilégios de acesso e definem a classificação da informação, se é 
confidencial, de uso interno ou público. 

Entretanto, a implantação de um sistema de gerenciamento da segurança 
da informação, por este ser amplo e abranger também as unidades de negócio, 
necessita de um forte patrocínio dentro da organização, assim como de um pro¬ 
grama contínuo de conscientização e de um pesado envolvimento da área de re¬ 
cursos humanos e das áreas que fazem contratação e uso de serviços de terceiros. 

O sistema de gerenciamento da segurança da informação pode ser implan¬ 
tado em etapas, focando, a princípio, os aspectos mais críticos de segurança 
da informação. Em algumas organizações, o problema está na segurança física 
do data center ,; em outras, o problema está na segurança lógica. 

A implantação deve ser considerada um projeto ou programa de longa 
duração. Dependendo da natureza da organização, pode requerer dois anos 
ou mais; desde que, naturalmente, sejam feitos os investimentos necessários. 

Em organizações mais maduras em termos de governança corporativa, a 
área responsável pelo sistema de gerenciamento da segurança da informação é 
estratégica e está fora da alçada da área de tecnologia da informação. 

Por fim, as novas tecnologias como computação em nuvem, big data, mí¬ 
dias sociais e BYOD (bringyour own devicé) têm um grande impacto no siste¬ 
ma de gestão de segurança da informação da organização (vide o Capítulo 14 
do livro, onde são explorados os processos de TI mais demandados conforme 
essas novas tecnologias). 


10.5 Benefícios do modelo 

Os benefícios da segurança da informação estão na prevenção de perdas 
financeiras que a organização pode ter, no caso da ocorrência de incidentes de 
segurança da informação. A organização também pode abalar a sua imagem 
ou sofrer ações na justiça pelas perdas que seus sistemas possam causar aos 
seus clientes. 

Diariamente tomamos conhecimento de notícias de fraudes digitais, perdas 
de dados de clientes, intrusões em redes e sistemas de informação sensíveis para 
as organizações e que se traduzem em prejuízos de milhões e milhões de reais. 
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Acreditamos que, quanto mais a empresa estiver interligada com seus for¬ 
necedores, clientes e usuários, maiores são as chances de ocorrência de inci¬ 
dentes em segurança da informação que possam trazer perdas financeiras. 

De acordo com um estudo do Comitê Gestor da Internet no Brasil (vide 
www.cert.br), o Brasil é um dos maiores emissores de spam e phishing , sendo 
que as fraudes desse tipo têm aumentado significativamente. 


10.6 Certificações relacionadas 

A certificação neste caso é do Sistema de Gestão da Segurança da Informa¬ 
ção (ISMS) da organização, podendo englobar a empresa como um todo ou 
uma operação específica. 

A empresa é certificada na norma ISO/IEC 27001. O ISMS não precisa 
compreender todos os controles preconizados na própria norma e detalhados 
na ISO/IEC 27002, mas somente aqueles que são aplicáveis à situação de 
cada empresa. 

Os controles são selecionados de acordo com as vulnerabilidades, os riscos, as 
obrigações contratuais, os requisitos legais e de regulação submetidos à empresa. 

No âmbito pessoal, existe a certificação ISO/IEC 27002 Foundation , que 
visa atestar a proficiência dos profissionais nos fundamentos da norma. 


10.7 Gestão da Continuidade do Negócio 

Em 2006 foi lançada, pelo British Institute of Standards, a norma BS 
25999-1:2006, que trata da gestão da continuidade do negócio ou Business 
Continuity Management - BCM. Esta parte da norma é o código de práticas. 
No Brasil, a norma correspondente é a NBR 15999-1:2007. 

Em 2007, foi publicada a BS 25999-1:2007, que é a especificação da nor¬ 
ma com a qual se pode obter a certificação do sistema de Gerenciamento da 
Continuidade do Negócio - GCN. 

Em 2012 esta norma foi substituída por duas normas ISO que tratam do 
Sistema de Gestão da Continuidade do Negócio, são elas: 

□ ISO 22.301:2012, Societal security — Business continuity management 
systems — Requirements. 
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□ ISO 22.313:2012, Societalsecurity — Business continuity management 
systems — Guidance. 

Essas normas já estão dentro do padrão de sistemas de gestão e podem ser 
integradas com outros sistemas de gestão. 

A ISO 22301 especifica os requisitos para planejar, estabelecer, imple¬ 
mentar, operar, monitorar, rever e melhorar continuamente o sistema do¬ 
cumentado de gestão da continuidade do negócio que é preparado para 
responder e recuperar o negócio de eventos que possam causar interrupções 
no negócio. 

A ISO 22313 fornece guias, exemplos e orientação para apoiar na imple¬ 
mentação de um sistema de gestão de continuidade de negócio baseado na 
norma 22301. 


10.8 Outras normas ISO relativas à 

SEGURANÇA DA INFORMAÇÃO 

Para segurança da informação, a ISO possui outras normas, tais como: 

□ ISO/IEC 15408 95 , que trata de critérios de avaliação para a segu¬ 
rança de TI, também conhecida como Common Criteria for Infor¬ 
mation Technology Security Evaluation. De acordo com esta nor¬ 
ma, pode-se certificar software, garantindo ao cliente que atenda 
a requisitos de segurança. A norma estabelece os seguintes níveis 
de Evaluation Assurance Levei, testado funcionalmente, estrutu¬ 
ralmente, metodicamente verificado, metodicamente projetado, 
testado e revisado e projetado e testado semiformalmente. Esta 
norma pode ser usada como detalhamento de implantação dos 
controles relativos ao desenvolvimento de sistemas estabelecidos 
pela ISO/IEC 27002. 

□ ISO/IEC 27031, que descreve conceitos e práticas da prontidão da 
tecnologia da informação e comunicação para a continuidade do ne¬ 
gócio e fornece um framework com métodos e processos para identifi¬ 
car e especificar todos os aspectos (tais como critérios de desempenho, 


95 Vide em Albuquerque & Ribeiro (2002) a aplicação dessa norma. 
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projeto e implementação) para melhorar a prontidão da TI, visando 
assegurar a continuidade do negócio. Aplica-se a qualquer tipo de 
organização e é uma norma que pode estar vinculada à ISO 22301. 

□ ISO/IEC 27033, que trata de segurança em redes. 

□ ISO/IEC 11770, que trata do gerenciamento de certificados e chaves 
digitais. 

□ ISO/IEC 27035, que trata do gerenciamento de incidentes de segu¬ 
rança da informação. 

□ ISO/IEC 27036, que trata de segurança da informação para o rela¬ 
cionamento com fornecedores. 

□ ISO/IEC 29100, que trata do esquema de privacidade. 

□ ISO/IEC 31000 , que trata do gerenciamento de riscos da organização. 

Há dezenas de normas relativas à segurança da informação, que tratam 
desde o vocabulário usado até o estabelecimento de requisitos para segurança 
de arquitetura em sistemas abertos, acesso remoto às bases de dados, cripto¬ 
grafia, autenticação de mensagens, biometria, identificação pessoal etc. Veja 
em www.iso.org para obter mais informações. 




Modelos para Gerenciamento de 
Sourcing 


Há basicamente duas linhas principais de modelos de gerenciamento para 
sourcing, tanto do ponto de vista do provedor do serviço como do cliente 
(comprador de serviços). 

Essas duas linhas são representadas pelos modelos desenvolvidos pelo ITsqc 
(Information Technology Services Qualification Center) e pelo Software Engineer- 
ing Institute. O primeiro desenvolveu os modelos eSCM-SP e eSCM-CP e o 
segundo, o CMMIfor Acquisition. 

Neste capítulo, apresentaremos um resumo desses modelos. 


11.1 eSCM-SP 

11.1.1 Histórico do modelo 

O eSCM-SP ou The eSourcing Capability Model for Service Providers é um 
modelo orientado exclusivamente para operações de sourcing, que atende não 
somente a serviços de TI, mas a outros serviços que usam a tecnologia da 
informação. 

Sua primeira versão é de novembro de 2001. A versão atual (2.01) foi 
desenvolvida por um consórcio de empresas e instituições lideradas pela Car- 
negie Mellon University, a mesma universidade que administra o Software 
Engineering Institute, mantenedor do CMMI, e publicada em 2006. 

Este modelo contou com uma vigorosa participação brasileira, através da 
Coordenação dos Programas de Pós-Graduação em Engenharia (COPPE), da 
Universidade Federal do Rio de Janeiro, instituição que fez parte do consórcio 
que mantinha o eSCM-SP. 



416 Implantando a Governança de TI - 4 a edição 


Para o desenvolvimento, a manutenção e a evolução do modelo foi criado 
o Information Technology Services Qualification Center - ITsqc (vide Hyder, 
Heston & Paulk, 2004). 

Em 2009, o ITsqc recebeu uma licença da Carnegie Mellon e tornou-se 
uma firma independente desta universidade. Em 2011, firmou convênio com 
a International Association of Outsourcing Professionals (IAOP) para manter o 
esquema de certificação do modelo. 


11 . 1.2 Objetivos do modelo 

Os objetivos do modelo são: 

□ Fornecer aos provedores de serviços orientação para melhorar a sua 
capacidade ao longo do ciclo de sourcing. 

□ Prover aos clientes meios objetivos de avaliar a capacidade do forne¬ 
cedor de serviços. 

□ Fornecer um padrão para que os fornecedores se diferenciem dos 
competidores. 

Este modelo, assim como o CMMI, exige reavaliações periódicas e tam¬ 
bém mantém credenciamentos para avaliadores certificados, consultores e 
instrutores. 


11 . 1.3 Estrutura do modelo 

O modelo é composto por 84 práticas (melhores práticas) organizadas ao 
longo de um ciclo de vida do sourcing , agrupadas por área de capacitação e 
nível de capacitação. 


Cid 


:1o de 


sourcing 


O ciclo de sourcing é composto pelas seguintes fases: ongoing, iniciação, 
entrega e encerramento ( completion ). 

A fase ongoing ocorre ao longo de todo o ciclo de sourcing , representando 
as funções gerenciais necessárias em todo o ciclo. Esta fase abrange: 
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□ Gerenciar e motivar as pessoas para entrega efetiva dos serviços. 

□ Gerenciar os relacionamentos com clientes, fornecedores e parceiros 
de negócios. 

□ Medir e rever o desempenho organizacional e tomar ação corretiva 
para melhorar o desempenho. 

□ Gerenciar a informação e o conhecimento, de forma que as pessoas 
possam usá-los para desempenhar seu trabalho. 

□ Identificar e controlar ameaças à habilidade da organização para aten¬ 
der a seus objetivos e aos requisitos dos clientes. 

□ Gerenciar a infraestrutura de tecnologia usada para apoiar a entrega 
dos serviços. 

A fase de iniciação contempla: 

□ Preparar a negociação das posições da organização prestadora de ser¬ 
viços (inclusive preço). 

□ Entender os requisitos do cliente. 

□ Analisar a habilidade da empresa para atender aos requisitos do 
cliente. 

□ Discutir junto ao cliente as premissas do trabalho. 

□ Estabelecer um acordo formal com o cliente. 

□ Gerenciar a transferência dos recursos necessários para a entrega dos 
serviços. 

□ Articular claramente a especificação dos serviços a serem prestados. 

□ Verificar se o projeto dos serviços está atendendo aos requisitos acor¬ 
dados com o cliente. 

□ Gerenciar o projeto e a implantação do serviço. 

A fase de entrega contempla: 

□ Planejar e controlar a entrega dos serviços. 

□ Entregar os serviços conforme os requisitos acordados com o 
cliente. 

□ Prover treinamento para os clientes e usuários finais, de forma que 
possam usar adequadamente os serviços. 
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□ Gerenciar os aspectos financeiros associados com a entrega dos 
serviços. 

□ Identificar e controlar mudanças nos serviços em relação ao que foi 
acordado. 

□ Identificar problemas que afetam os serviços e tomar ações corretivas 
e preventivas. 

A fase de encerramento contempla: 

□ Gerenciar a transferência dos serviços para outro provedor de serviços. 

□ Assegurar a continuidade dos serviços durante a transferência dos 
serviços. 

□ Identificar e transferir capital intelectual para a entrega do serviço. 


Áreas de capacidade 


As áreas de capacidade representam o agrupamento lógico das práticas as¬ 
sociadas ao ciclo de sourcing e servem para demonstrar a capacidade do pro¬ 
vedor do serviço. 

O modelo contém dez áreas de capacidade (descritas em termos de seus 
principais componentes): 

□ Gestão do conhecimento : demonstração do comprometimento com 
o compartilhamento de conhecimento, a política específica, a gestão 
dos ativos de processo, o controle de configuração dos produtos de 
trabalho e a manutenção de lições aprendidas. 

□ Gestão de pessoas : demonstração do comprometimento e da par¬ 
ticipação das pessoas na tomada de decisão, desenvolvimento de 
carreira, fornecimento de ambiente de trabalho adequado, defi¬ 
nição clara de papéis e responsabilidades, identificação de neces¬ 
sidades de competências e seu desenvolvimento, contratação de 
pessoal e fornecimento de avaliação de desempenho periódico para 
o pessoal. 
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□ Gestão do desempenho : definição dos objetivos organizacionais e sua 
avaliação, estabelecimento de programas organizacionais, identifica¬ 
ção e implantação de melhorias de desempenho, medição da capa¬ 
cidade da empresa como base para a melhoria, realização de bench¬ 
marking, fornecimento de recursos para a avaliação do desempenho 
e implantação das inovações em toda a empresa de forma a melhorar 
o desempenho global. 

□ Gestão do relacionamento : gerenciamento do relacionamento com o 
cliente, fornecedores e parceiros, gerenciamento das interações com 
os clientes, seleção de fornecedores e parceiros com base em sua capa¬ 
cidade de atender aos requisitos e avaliar seu desempenho, obtenção 
de feedback do cliente para melhorar o relacionamento e identificação 
de oportunidades para adicionar valor ao cliente e aos fornecedores 
e parceiros. 

□ Gestão da tecnologia : gerenciamento da aquisição de tecnologia, im¬ 
plantação de tecnologia, integração da infraestrutura tecnológica da 
organização com a do cliente e de outros fornecedores, gerenciamen¬ 
to das tecnologias licenciadas e otimização do desempenho da infra¬ 
estrutura tecnológica. 

□ Gestão de ameaças : demonstração de compromisso com políticas de 
gestão de riscos, identificação, controle e avaliação de riscos, gestão 
da segurança, propriedade intelectual, preparação para recuperação 
de desastres, gestão da recuperação de desastres e monitoramento de 
requisitos de compliance. 

□ Contratação : preparação para negociação, entendimento dos requisi¬ 
tos do cliente, análise da capacidade da organização para atender às 
necessidades e aos requisitos do cliente, trabalho em conjunto com o 
cliente para determinar premissas dos serviços e estabelecer um acor¬ 
do formal. 

□ Projeto e implantação do serviço : especificação dos serviços a serem 
fornecidos, obtenção de feedback do projeto do serviço para verificar 
se está atendendo às especificações, gerenciamento do projeto do ser¬ 
viço e sua implantação. 

□ Entrega do serviço : planejamento e monitoramento das atividades de 
entrega dos serviços, entrega dos serviços de acordo com os requisitos, 
fornecimento de treinamentos para os clientes e usuários finais para 
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uso dos serviços, gerenciamento dos aspectos financeiros dos serviços, 
identificação e controle das mudanças nos serviços e identificação de 
problemas que possam impactar os serviços. 

□ Transferência do serviço : gerenciamento da transferência dos recursos 
para a operação de sourcing, transferência de recursos de volta para o 
cliente ou para outro provedor de serviço, garantia de continuidade 
de serviço durante a transferência de recursos e identificação e trans¬ 
ferência do capital intelectual crítico para os serviços. 


Níveis de capacidade 


Da mesma forma que outros modelos, este também tem cinco níveis de 
capacidade, que mostram o caminho de evolução do fornecedor de serviços 
rumo à excelência em serviços. Esses níveis são: 

□ Nível 1 - Provedor de Serviços : pode ter algumas práticas do modelo, 
mas geralmente promete mais do que pode cumprir. 

□ Nível 2 - Atendendo Consistentemente aos Requisitos : fornece de 
forma consistente os serviços de acordo com os requisitos do cliente, 
sabe como definir os requisitos, como implantar e entregar os serviços 
e realiza todas as práticas do nível 2. 

□ Nível 3 - Gerenciamento do Desempenho Organizacional : tem ca¬ 
pacidade de prover os serviços (mesmo que sejam diferentes de sua 
experiência passada), gerencia o desempenho por toda a organiza¬ 
ção, sabe como identificar riscos na aceitação dos serviços, projeta 
e implanta os serviços de acordo com procedimentos, gerencia a in- 
fraestrutura tecnológica, gerencia o conhecimento, mede e premia 
o desempenho das pessoas. Está sempre melhorando o desempenho 
dos serviços (embora as melhorias ainda sejam reativas) e realiza todas 
as práticas dos níveis 2 e 3. 

□ Nível 4 - Fornecendo Valor Proativamente : inova nos serviços para 
os clientes, sendo capaz de personalizar os serviços para os clientes e 
demais interessados, entende as necessidades do negócio do cliente, 
está sempre incorporando avanços tecnológicos, estabelece objetivos 
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a partir de análises estratégicas e benchmarking. Geralmente planeja, 
implanta e controla suas próprias melhorias e atende a todas as práti¬ 
cas dos níveis 2, 3 e 4. 

□ Nível 5 - Sustentando a Excelência : mantém a excelência em servi¬ 
ços, executando as práticas dos níveis 2, 3 e 4 durante duas ou mais 
avaliações de certificação consecutivas, em um período de pelo menos 
dois anos. 


A relação entre o ciclo de sourcing ., áreas de capacidade e níveis de 
capacidade. 


A Figura 11.1 mostra o relacionamento entre as três dimensões do 
eSCM-SP. 



Figura 11.1 - As dimensões do eSCM-SP 
Fonte: Hyder, Heston & Paulk (2006) 
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Uma mesma área de capacidade pode estar em mais de uma fase do ciclo 
de sourcing e em mais de um nível de capacidade. Isso acontece porque as 
práticas que constituem uma área de capacidade estáo distribuídas ao longo 
do ciclo de sourcing e pelos níveis de capacidade. 

A Tabela 11.1 relaciona as práticas das áreas de capacidade com os níveis 
de capacidade. 


Níveis de 
capacidade 

Áreas de capacidade 

Prática 

Nível 2 

Gestão do conhecimento 

• Fornecimento da informação requerida. 

• Controle de mudança e versão. 

• Consumo de recursos. 


Gestão de pessoas 

• Ambiente de trabalho. 

• Atribuição de responsabilidades. 

• Competências do pessoal. 


Gestão do desempenho 

• Objetivos da operação. 

• Verificação de processos. 

• Recursos adequados. 


Gestão do relacionamento 

• Interações com os clientes. 

• Seleção de fornecedores e parceiros. 

• Gestão de fornecedores e parceiros. 


Gestão da tecnologia 

• Aquisição de tecnologia. 

• Licenciamento de tecnologias. 

• Controle da tecnologia. 

• Integração da tecnologia. 


Gestão de ameaças 

• Gestão de risco. 

• Riscos da operação. 

• Segurança. 

• Propriedade intelectual. 

• Compliance. 

• Recuperação de desastre. 


Contratação 

• Precificação. 

• Confirmação das condições existentes. 

• Plano de negociações. 

• Obtenção de requisitos. 

• Revisão de requisitos. 

• Resposta aos requisitos. 

• Papéis no contrato. 

• Criar contratos. 

• Aditivos contratuais. 
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Níveis de 
capacidade 

Áreas de capacidade 

Prática 


Projeto e implantação do serviço 

• Comunicação dos requisitos. 

• Plano do projeto e da implantação. 

• Especificação do serviço. 

• Projeto do serviço. 

• Feedback do projeto. 

• Implantação do serviço. 


Entrega do serviço 

• Plano de entrega do serviço. 

• Treinamento de clientes. 

• Entrega do serviço. 

• Verificação de compromissos com o serviço. 

• Correção de problemas. 

• Modificações nos serviços. 

• Gestão financeira. 


Transferência dos serviços 

• Transferência de recursos para a operação. 

• Transferência de pessoal para a operação. 

• Transferência de recursos da operação. 

• Transferência de pessoal da operação. 

Nível 3 

Gestão do conhecimento 

• Sistema de conhecimento. 

• Ativos de processos. 

• Conhecimento de outras operações. 

• Reutilização. 


Gestão de pessoas 

• Participação e tomada de decisão. 

• Definição de papéis. 

• Competências da força de trabalho. 

• Plano e realização de treinamento. 

• Avaliação de desempenho. 

• Desenvolvimento de carreiras. 

• Recompensas. 


Gestão do desempenho 

• Objetivos organizacionais. 

• Revisão do desempenho organizacional. 

• Realização de melhorias. 


Gestão do relacionamento 

• Adequação cultural. 

• Informação dos interessados. 

• Relacionamentos com clientes. 

• Relacionamentos com fornecedores e parceiros. 


Gestão da tecnologia 

• Otimização da tecnologia. 


Gestão de ameaças 

• Riscos entre operações da organização. 


Contratação 

• Negociações. 

• Informações de mercado. 


Projeto e implantação do serviço 

• Projeto e implantação do serviço. 

• Verificação do projeto. 
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Níveis de 
capacidade 

Áreas de capacidade 

Prática 


Entrega do serviço 

• Prevenção de problemas conhecidos. 

Transferência de serviços 

• Continuidade do serviço. 

Nível 4 

Gestão do conhecimento 

• Compartilhamento do conhecimento. 

Gestão de pessoas 

• Incentivo à inovação. 

Gestão do desempenho 

• Atendimento dos objetivos organizacionais. 

• Criação de baselines do desempenho. 

• Benchmarking. 

• Prevenção de problemas potenciais. 

• Implantação de inovações. 

Gestão do relacionamento 

• Criação de valor. 

Gestão da tecnologia 

• Introdução proativa de tecnologias. 

Transferência de serviços 

• Transferência de conhecimento da operação. 


Tabela 11.1 - eSCM-SP: práticas por níveis de capacitação 
Adaptado de Hyder, Heston & Paulk (2006) 


11.1.4 Aplicabilidade do modelo 

O eSCM-SP aplica-se a fornecedores de serviços que utilizam a tecnologia 
da informação de forma intensiva, tais como: 

□ Serviços de engenharia. 

□ Captura de dados. 

□ Centrais de serviços. 

□ Compras. 

□ Recursos humanos. 

□ Serviços financeiros e contabilidade. 

□ Application Service providers. 

□ Data centers. 

□ Manutenção de computadores. 

□ Desenvolvimento e gestão de aplicações. 

□ Suporte de redes e telecomunicações. 
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11.1.5 Benefícios do modelo 

Os principais benefícios com a adoção do modelo pelos fornecedores de 
serviços são: 

□ Estabelecer e manter a confiança entre as partes. 

□ Gerenciar as expectativas das partes. 

□ Traduzir necessidades implícitas e explícitas em requisitos definidos 
com nível de qualidade acordado. 

□ Estabelecer contratos bem definidos. 

□ Rever o desdobramento dos serviços para assegurar a cobertura dos 
requisitos. 

□ Assegurar a eficácia das interações com os interessados relevantes. 

□ Gerenciar comprometimentos. 

□ Assegurar compliance com requisitos de regulação externos e internos. 

□ Gerenciar os aspectos de segurança requeridos pelo cliente. 

□ Gerenciar diferenças culturais. 

□ Monitorar e controlar as atividades para, de forma consistente, aten¬ 
der aos compromissos assumidos com o cliente e a organização. 

□ Monitorar a satisfação do cliente e dos usuários finais. 

□ Construir e manter competências dos profissionais. 

□ Gerenciar a satisfação, motivação e retenção de profissionais. 

□ Manter um bom ambiente de trabalho. 

□ Manter-se competitivo. 

□ Ser inovador e flexível para atender a necessidades únicas dos clientes. 

□ Gerenciar rapidamente mudanças tecnológicas. 

□ Capturar e usar conhecimento. 

□ Transferir de forma segura e ordenada os serviços prestados. 

□ Manter a continuidade dos serviços. 


11.1.6 Certificações relacionadas 

Uma organização provedora de serviços pode obter uma certificação de 
nível de capacitação, a partir de uma avaliação externa executada por uma 
organização autorizada pelo ITsqc. 

A Tabela 11.2, a seguir, mostra os Métodos de Determinação de Capaci¬ 
tação do modelo. 
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Autoavaliação 

Avaliação 

Avaliação para 
certificação 

FULL 

Propósito 

Para avaliar o progresso 
do esforço de melhoria; 
criar baseline ou prover 
uma prontidão visando 
uma certificação. 

Obter uma avaliação 
independente da 
implementação do 
modelo. 

Para diferenciar-se e 
ser verificado de forma 
independente e publicar 
o nível de capacitação 
obtido. 


Resultado 

Um perfil das práticas 
é fornecido para 
a organização, o 
patrocinador e o ITsqc; 
não é necessária uma 
certificação pelo ITsqc. 

Um perfil das práticas 
é fornecido para 
a organização, o 
patrocinador e o ITsqc; 
não é necessária uma 
certificação pelo ITsqc. 

Certificação pelo 

ITsqc de um nível de 
capacitação; o perfil 
das práticas é fornecido 
para a organização, o 
patrocinador e o ITsqc. 


Equipe 

Interna, externa ou 
combinação. Todos 
devem ser treinados no 
modelo e no método. 

Externo. Todos têm que 
ser autorizados pelo 

ITsqc. 

Externo. Todos têm que 
ser autorizados pelo 

ITsqc. 


Determinação 
do Líder da 
Equipe 

Deve ser um candidato 
ou um Avaliador Líder 
autorizado. 

Avaliador Líder 

Autorizado é requerido. 

Avaliador Líder 

Autorizado é requerido. 


Patrocinador 

Fornecedor de serviço ou 
o cliente. 

Fornecedor de serviço ou 
o cliente. 

Fornecedor de serviço ou 
o cliente. 


Escopo do 

Modelo 

Todas as práticas. 

Todas as práticas. 

Todas as práticas. 



Autoavaliação 

Avaliação 

Avaliação para 
certificação 

MINI 

Propósito 

Para lançar ou verificar 
progresso do esforço. 

Para rapidamente e 
economicamente, e de 
forma independente, 
obter uma verificação 
de capacidade para um 
conjunto reduzido de 
práticas. 



Resultado 

Perfil das práticas 
é fornecido para 
a organização, o 
patrocinador eo ITsqc; 
nenhum rating de 
capacidade é fornecido. 

Perfil das práticas 
é fornecido para 
a organização, o 
patrocinador e o ITsqc; 
nenhum rating de 
capacidade é fornecido. 




























Modelos para Gerenciamento de Sourcing 427 



Autoavaliação 

Avaliação 

Avaliação para 
certificação 

MINI 

Equipe 

Interna, externa ou 
combinação. Todos 
devem ser treinados no 
modelo e no método 
de determinação de 
capacitação. 

Externa. Todos devem 
ser autorizados pelo 
ITsqc. 



Determinação do Líder 
da Equipe 

Deve ser um candidato 
ou um Avaliador Líder 
autorizado. 

Somente um Avaliador 
Líder Autorizado. 



Patrocinador 

Fornecedor de serviços 
ou o cliente. 

Fornecedor de serviços 
ou o cliente. 



Escopo do Modelo 

Qualquer conjunto das 
práticas. 

Qualquer conjunto das 
práticas. 



Tabela 11.2 - Métodos de determinação de capacitação 
Fonte: Hyder, Heston & Paulk (2006) 


A certificação é feita por um Lead Evaluator credenciado, que faz parte de 
uma organização autorizada. 

O ITsqc também credencia organizações para fornecerem treinamentos no 
modelo através de instrutores autorizados. 


11.2 eSCM-CL 

11.2.1 Histórico do modelo 

O eSCM-CL ou The eSourcing Capability Model for Client Organizations 
começou a ser desenvolvido em 2003, motivado pelo fato de que um bom 
sourcing requer que as melhores práticas também sejam seguidas pelo compra¬ 
dor de serviços e não só pelo fornecedor. 

Durante o seu desenvolvimento, uma série de modelos foi analisada para 
identificar sua aplicabilidade para a questão de gestão do sourcing. Várias or¬ 
ganizações e instituições foram consultadas. 

Em setembro de 2003 foi realizado um workshop onde foram obtidas 
sugestões e recomendações da comunidade (pesquisadores, organizações e 
instituições). 
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Em 2004, várias entrevistas foram realizadas com organizações direta¬ 
mente envolvidas com o sourcing , visando identificar pontos importantes 
na sua gestão. A partir das entrevistas e worksbops o modelo começou a ser 
desenvolvido. Em fevereiro de 2005, foi realizado o quarto worksbop , focado 
na definição de Áreas de Capacidade e identificação das práticas em cada 
Área de Capacidade. 

Ainda em 2005, foi publicado o primeiro draft do modelo, para fins de 
avaliação e obtenção de sugestões e recomendações. Em 2006, testes piloto do 
método de Determinação de Capacidade (método de avaliação de maturida¬ 
de) começaram a ser realizados. 

Em setembro de 2006, a versão 1.1 do modelo foi liberada para a comu¬ 
nidade internacional. 


11.2.2 Objetivos do modelo 

Os principais objetivos do modelo são: 

□ Prover aos clientes um conjunto de melhores práticas para ajudá-los a 
melhorar suas capacidades em relação às atividades de sourcing. 

□ Ajudar as organizações clientes a estabelecer, gerenciar e sustentar a 
melhoria contínua nas suas relações de sourcing. 

□ Ajudar as organizações clientes a mitigar riscos nas suas relações de 
sourcing. 

□ Ajudar as organizações clientes a criar competência na gestão de suas 
atividades de sourcing. 

□ Assegurar a satisfação dos interessados relevantes ao longo do ciclo de 
vida do processo de sourcing. 

□ Prover meios para as organizações clientes avaliarem, de forma objeti¬ 
va, suas próprias capacidades em serviços de sourcing de TI. 


11.2.3 Estrutura do modelo 

A Figura 11.2 mostra o foco do eSCM-CL e sua relação com o eSCM-SP. 
A estrutura do modelo é mostrada pela Figura 11.3 a seguir. Como o leitor 
poderá observar, sua estrutura é similar à do eSCM-SP. A diferença é que, no 
ciclo de sourcing , há a atividade adicional de Análise. 
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Figura 11.2 - Visão da relação eSCM-CL e eSCM-SP 
Fonte: Hefley & Loesche (2006) 


Ongoing 



Análise 

Iniciação 

Entrega 



Encerramento 


Figura 11.3- Estrutura do eSCM-CL 
Fonte: Hefley & Loesche (2006) 
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Características do Ciclo de Sourcing 


O ciclo de sourcing é composto pelas seguintes fases: ongoing , análise, ini¬ 
ciação, entrega e encerramento (completiori). 

A fase ongoing cobre as seguintes atividades: 

□ Desenvolver a estratégia de sourcing. 

□ Gerenciar e motivar o pessoal para gerenciar atividades de sourcing. 

□ Gerenciar o relacionamento com fornecedores de serviços e os inte¬ 
ressados relevantes internos. 

□ Medir e rever o desempenho das atividades de sourcing e tomar medi¬ 
das para a sua melhoria. 

□ Definir o estado futuro da organização e de seus processos, relativa¬ 
mente ao sourcing. 

□ Gerenciar as mudanças organizacionais decorrentes. 

□ Gerenciar a informação e os sistemas de conhecimento de forma que 
o pessoal tenha acesso às informações necessárias para desempenhar 
o seu trabalho. 

□ Identificar e controlar as ameaças à organização em relação a atender 
seus objetivos e gerenciar de forma bem-sucedida os seus relaciona¬ 
mentos de sourcing. 

□ Assegurar que a arquitetura e a infraestrutura usadas para suportar o 
serviço sejam gerenciadas. 

A fase de análise contempla: 

□ Entender a situação atual em termos de processos e estrutura do cliente. 

□ Identificar critérios relevantes para selecionar oportunidades de sourcing. 

□ Identificar oportunidades de sourcing para atender aos critérios 
identificados. 

□ Analisar as opções de sourcing. 

□ Desenvolver e analisar um Business Case para cada opção de sourcing. 

□ Identificar a abordagem de sourcing e o modelo de governança para a 
ação de sourcing proposta. 

□ Desempenhar análise de impacto e risco das ações propostas de sourcing. 

□ Tomar a decisão se vai realizar o sourcing ou não. 
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A fase de iniciação contempla: 

□ Preparar-se para a seleção do serviço, desenvolvendo a solicitação e o 
critério de seleção. 

□ Solicitar e avaliar potenciais fornecedores de serviços. 

□ Preparar-se para as negociações, tendo posições sobre custo e outros 
tópicos necessários para a negociação. 

□ Definir os níveis de serviços e medições de desempenho do fornecedor. 

□ Entender as capacitações do fornecedor de serviços pela obtenção 
de informação sobre este, confirmando premissas que impactam nos 
compromissos. 

□ Estabelecer um acordo formal com o fornecedor de serviços, que ar¬ 
ticule claramente as responsabilidades e os compromissos de ambas 
as partes. 

□ Fornecer feedback sobre o projeto do serviço, a fim de assegurar que os 
serviços atendam aos requisitos do cliente e aos compromissos acordados. 

□ Gerenciar a efetiva transferência dos recursos necessários para a en¬ 
trega do serviço, incluindo pessoal, infraestrutura tecnológica e am¬ 
biente de trabalho. 

A fase de entrega contempla: 

□ Planejar e controlar as atividades de gestão de sourcing. 

□ Assegurar que os serviços sejam entregues de acordo com os compro¬ 
missos acordados. 

□ Gerenciar as finanças associadas com a entrega do serviço. 

□ Identificar e controlar as modificações aos serviços que são fornecidos 
ou aos compromissos associados aos serviços. 

□ Facilitar a resolução de problemas que impactam na entrega do serviço. 

□ Reconciliar o desempenho em relação às expectativas e assegurar que 
a provisão de serviços crie valor para a organização cliente. 

A fase de encerramento contempla: 


□ Planejar o encerramento do serviço contratado e gerenciar os acordos 
durante esse período até o seu encerramento normal ou renovação. 
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□ Gerenciar a efetiva transferência de recursos para o novo forne¬ 
cedor de serviços, seja este o próprio cliente ou outro fornecedor, 
incluindo transferência de pessoas, infraestrutura e propriedade 
intelectual. 

□ Assegurar a continuidade do serviço durante a transferência de res¬ 
ponsabilidades para a provisão dos serviços. 

□ Identificar e transferir o conhecimento crítico para a entrega dos serviços. 


Áreas de capacidade 


As áreas de capacidade representam o agrupamento lógico das práticas as¬ 
sociadas ao ciclo de sourcing e servem para demonstrar a capacidade da orga¬ 
nização cliente. 

As áreas de capacidade relacionam-se com as fases do ciclo de sourcing , 
conforme mostra a Tabela 11.3, a seguir: 


Fases do ciclo de vida de sourcing 

Áreas de capacidade 

Ongoing 

• Gestão da estratégia de sourcing. 

• Gestão da governança. 

• Gestão do relacionamento. 

• Gestão do valor. 

• Gestão da mudança organizacional. 

• Gestão de pessoas. 

• Gestão do conhecimento. 

• Gestão da tecnologia. 

• Gestão de ameaças. 

Análise 

• Análise de oportunidades de sourcing. 

• Abordagem de sourcing. 

Iniciação 

• Planejamento do sourcing. 

• Avaliação de fornecedor de serviço. 

• Acordos de serviços. 

• Transferência de serviços. 

Entrega 

• Gestão dos serviços contratados. 

Encerramento 

• Encerramento do sourcing. 


Tabela 11.3- Áreas de capacitação versus ciclo de sourcing 
Adaptado de Hefley & Loesche (2006) 
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A seguir é fornecida uma breve descrição de cada área de capacitação do 
modelo eSCM-CL: 

□ Gestão da estratégia de sourcing . foca a determinação da estratégia de 
sourcing e o estabelecimento de objetivos organizacionais ou metas 
para o sourcing. A estratégia de sourcing considera a maneira como 
estruturá-lo, o que contratar, as formas de contratação, o desenvolvi¬ 
mento de alianças e parcerias etc. 

□ Gestão da governança : foca o estabelecimento da estrutura organi¬ 
zacional e dos processos gerenciais organizacionais, procedimentos e 
processos específicos para o sourcing. Além disso, realiza o alinhamen¬ 
to das atividades de sourcing com o negócio. 

□ Gestão do relacionamento : foca o estabelecimento e o gerenciamen¬ 
to de relacionamentos de longo prazo com os provedores de servi¬ 
ços. A gestão do relacionamento ocorre ao longo de todo o ciclo de 
sourcing. 

□ Gestão do valor : foca a promoção e o gerenciamento da cultura de 
melhoria contínua, de forma que o cliente perceba valor no seu en¬ 
gajamento com o sourcing, assim como a garantia de que a estratégia 
e o desempenho do sourcing estejam alinhados com os objetivos da 
organização. Revê e analisa o desempenho e a estratégia do sourcing 
para alinhamento ao negócio e promove a inovação através da insti¬ 
tucionalização de uma nova cultura, visando a melhoria contínua no 
relacionamento, de forma a superar as expectativas dos interessados 
relevantes. 

□ Gestão da mudança organizacional : foca o processo de gerenciamen¬ 
to da mudança para guiar a adoção pelo cliente dos novos sistemas 
(organizacionais e tecnológicos) e das novas formas de atingir os obje¬ 
tivos do negócio através do sourcing. Esta área de capacitação cobre o 
planejamento para a gestão da mudança, o desenho do estado futuro, 
a comunicação, o gerenciamento dos aspectos humanos da mudança 
e a gestão da mudança propriamente dita. 

□ Gestão de pessoas : foca a provisão e o gerenciamento de recursos qua¬ 
lificados e do ambiente necessário para as atividades de sourcing. Co¬ 
bre o entendimento dos papéis no modelo de sourcing da organização 
e o desenvolvimento de competências correspondentes. 
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□ Gestão do conhecimento : foca o gerenciamento da informação e o 
sistema de conhecimento, de forma que as pessoas envolvidas te¬ 
nham fácil acesso ao conhecimento necessário para desempenhar 
o seu trabalho. Cobre a provisão do acesso à informação sobre o 
sourcing , lições aprendidas, informações acerca do mercado e dos 
fornecedores. 

□ Gestão da tecnologia : foca a gestão da estratégia e arquitetura 
tecnológica e o monitoramento e gerenciamento da infraestrutu- 
ra. Cobre a gestão da mudança tecnológica e a gestão dos ativos 
tecnológicos. 

□ Gestão de ameaças : foca a identificação e o gerenciamento ati¬ 
vo de ameaças à habilidade da organização cliente para atender 
aos objetivos do negócio e do sourcing. Cobre temas como gestão 
de riscos, proteção contra ameaças, continuidade do negócio e 
compliance. 

□ Análise de oportunidades de sourcing . foca a análise funcional das 
operações atuais da organização e a identificação de funções, pro¬ 
cessos e serviços com potencial para serem terceirizadas em parte 
ou totalmente. Cobre temas como entendimento da situação atual, 
determinação de critérios de seleção e análise de oportunidades de 
sourcing. 

□ Abordagem de sourcing . foca a decisão sobre o tipo de sourcing para 
uma oportunidade específica. Cobre temas como determinação da 
abordagem proposta de sourcing , elaboração de Business Case , análises 
de impacto e risco e decisão para o sourcing. 

□ Planejamento de sourcing . foca o planejamento da implementação 
da abordagem de sourcing para as iniciativas planejadas. Cobre temas 
como projeto de sourcing , plano de sourcing e definição de requisitos 
e acordos. 

□ Avaliação do fornecedor de serviço : foca a identificação de potenciais 
fornecedores de serviços e a seleção dos principais fornecedores. Co¬ 
bre a seleção do fornecedor de serviço, considerando a avaliação de 
potenciais prestadores de serviços. 

□ Acordos de serviços : foca a confirmação do serviço, a negociação dos 
termos e as condições do contrato, incluindo níveis de serviços. Co- 
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bre a preparação para negociações, a definição de metas e medições e 
a confirmação de capacidades e negociações. 

□ Transferência de serviços : foca a transferência bem-sucedida de re¬ 
cursos entre a organização cliente e o fornecedor pela criação e im¬ 
plementação de um plano de transferência. Cobre a gestão da trans¬ 
ferência do serviço, a verificação, a transferência de conhecimento, 
pessoas e habilidades e a transferência de recursos. 

□ Gestão dos serviços contratados : foca a obtenção da capacidade para 
o gerenciamento dos serviços contratados e os problemas que podem 
surgir relativamente ao andamento dos serviços. Cobre a monitora¬ 
ção do desempenho, o gerenciamento financeiro, o gerenciamento 
do contrato, o gerenciamento do relacionamento, o gerenciamento 
das mudanças e análises de valor. 

□ Encerramento do sourcing . foca o planejamento e a execução de ati¬ 
vidades para o encerramento do relacionamento/projeto e a garantia 
de que isso seja feito de forma suave. Cobre temas como análise dos 
resultados do sourcing , continuidade do serviço, documentação dos 
resultados e encerramento formal. 


Níveis de capacidade 


Da mesma forma que outros modelos, este também tem cinco níveis de 
capacidade, que mostram o caminho de evolução do cliente de serviços rumo 
à excelência em gestão de sourcing. Esses níveis são: 

□ Nível 1 - Executando o sourcing; . poucas práticas do eSCM-CL im¬ 
plementadas, alto risco de insucesso no sourcing , pouca capacidade 
de gestão do sourcing e pouco alinhamento com as necessidades do 
negócio. 

□ Nível 2 - Gerenciando o sourcing consistentemente : as organizações 
clientes têm procedimentos formalizados para o gerenciamento de 
suas atividades de sourcing e são capazes de gerenciar o sourcing , mas 
não da mesma maneira no âmbito da organização inteira. Neste 
nível, há o suporte executivo, assim como objetivos para sourcing. 
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Os fornecedores de serviços sáo selecionados e gerenciados, as opor¬ 
tunidades e partes interessadas relevantes sáo identificadas e é asse¬ 
gurado que o pessoal que faz a gestáo do sourcing tenha as habilida¬ 
des e os conhecimentos necessários para gerenciá-lo e monitorá-lo 
através de medidas de desempenho. Organizações clientes no nível 
2 implementaram todas as práticas desse nível e podem demonstrar 
seu uso efetivo. 

□ Nível 3 - Gerenciando o desempenho do sourcing em âmbito orga¬ 

nizacional : neste nível, as organizações clientes são capazes de ge¬ 
renciar o desempenho do sourcing de acordo com a estratégia da 
organização, de entender o mercado e os provedores de serviços 
(incluindo atributos culturais), de identificar e gerenciar os riscos 
e de gerenciar o sourcing com base em processos organizacionais 
estabelecidos. Além disso, tentam melhorar, de forma contínua, sua 
capacidade de gerenciamento do sourcing. Entretanto, a melhoria 
das atividades ainda é reativa. Para que uma organização cliente seja 
considerada nível 3, precisa demonstrar todas as práticas dos níveis 
2 e 3, simultaneamente. 

□ Nível 4 - Aperfeiçoando o valor proativamente : neste nível, as orga¬ 
nizações clientes sáo capazes de inovar continuamente para adicionar 
valor significativo às atividades de sourcing , estando aptas a “customi¬ 
zarem” sua abordagem de sourcing em funçáo de vários fornecedores 
e tipos de serviços, a desenvolverem relacionamentos que agreguem 
valor ao negócio, encorajando inovaçáo, a entenderem o valor de suas 
atividades de sourcing e a prever o desempenho baseado em experi¬ 
ências prévias. As metas de desempenho sáo estabelecidas continua¬ 
mente, a partir da análise da situação atual, assim como com o uso 
de benchmarking. Neste nível, as organizações clientes planejam, im¬ 
plementam e controlam seu próprio aperfeiçoamento. Para que uma 
organização cliente seja considerada no nível 4, deve demonstrar as 
práticas dos níveis 2, 3 e 4. 

□ Nível 5 - Sustentando a Excelência : mantém a excelência em servi¬ 
ços, executando as 95 práticas dos níveis 2, 3 e 4 durante duas ou 
mais avaliações de certificação consecutivas, em um período de pelo 
menos dois anos. Não há práticas adicionais neste nível. 
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De acordo com o modelo, no nível 2 encontram-se 57 práticas, no nível 3 , 
trinta práticas e no nível 4, oito práticas. 

Em relaçáo ao ciclo de sourcing , cinquenta práticas estáo no ongoing , nove 
em análise , vinte em iniciação, onze em entrega e cinco em encerramento . 

A Tabela 11.4, a seguir, apresenta as áreas de capacidade e práticas por nível 
de capacidade. 


Níveis de 
capacidade 

Áreas de capacidade 

Prática 

Nível 2 

Gestão da estratégia de sourcing 

• Patrocínio do sourcing. 

• Restrições ao sourcing. 

• Áreas potenciais de sourcing. 

• Objetivos de sourcing. 


Gestão da governança 

• Gestão do fornecedor de serviço. 

• Gestão do interessado relevante interno. 


Gestão do relacionamento 

• Interações com os fornecedores. 

• Gestão de problemas. 


Gestão da mudança organizacional 

• Envolvimento dos interessados relevantes. 

• Mudança organizacional. 


Gestão de pessoas 

• Atribuição de responsabilidades pelo 
sourcing. 

• Competências de pessoal. 


Gestão do conhecimento 

• Prover a informação requerida. 


Gestão da tecnologia 

• Gestão de ativos. 

• Gestão de licenças. 

• Integração da tecnologia. 


Gestão de ameaças 

• Gestão do risco do sourcing. 

• Propriedade intelectual. 

• Segurança e privacidade. 

• Compliance. 

• Continuidade do negócio. 


Análise de oportunidades de sourcing 

• Identificação da demanda. 

• Opções de sourcing. 


Abordagem de sourcing 

• Abordagem de sourcing. 

• Business case. 

• Modelo de governança. 

• Decisão da iniciativa de sourcing. 
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Níveis de 
capacidade 

Áreas de capacidade 

Prática 

Nível 2 

Planejamento do sourcing 

• Estabelecimento do projeto de sourcing. 

• Definição do serviço. 

• Procedimentos de seleção do provedor de 
serviços. 

• Critérios de avaliação. 

• Preparação dos requisitos dos serviços. 


Avaliação do fornecedor de serviço 

• Comunicação dos requisitos. 

• Avaliação dos potenciais fornecedores de 
serviços. 

• Seleção dos fornecedores de serviços 
candidatos. 


Acordos de serviços 

• Confirmação das condições existentes. 

• Negociações. 

• Papéis no acordo. 

• Definição de acordos de níveis de serviços e 
medições. 

• Criar contratos. 

• Aditar contratos. 


Transferência de serviços 

• Transferência de recursos para o fornecedor 
de serviços. 

• Transferência de pessoal para o fornecedor 
de serviços. 

• Transferência de conhecimento para o 
fornecedor de serviços. 


Gestão dos serviços contratados 

• Gestão da mudança no serviço. 

• Revisão do desempenho do serviço. 

• Decisão de continuação. 


Encerramento do sourcing 

• Planejamento do encerramento. 

• Recursos transferidos do fornecedor de 
serviços. 

• Pessoas transferidas do fornecedor de 
serviços. 

• Conhecimento transferido do fornecedor de 
serviços. 

Nível 3 

Gestão da estratégia de sourcing 

• Estratégia de sourcing organizacional. 


Gestão da governança 

• Política de sourcing. 

• Definição dos processos de sourcing. 

• Alinhamento das estratégias e arquiteturas. 

• Integração com os processos de negócio. 

• Adaptação às mudanças do negócio. 
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Níveis de 
capacidade 

Áreas de capacidade 

Prática 

Nível 3 

Gestão do relacionamento 

• Relacionamento com fornecedores de 
serviços. 

• Relacionamentos internos. 

• Integração cultural. 

Gestão do valor 

• Desempenho organizacional do sourcing. 

• Aperfeiçoamento dos processos de sourcing. 

Gestão da mudança organizacional 

• Preparação para a mudança organizacional. 

• Projeto do estado futuro. 

• Mudanças em recursos humanos. 

• Comunicação das mudanças organizacionais. 

Gestão de pessoas 

• Competência organizacional em sourcing. 

• Definição de papéis. 

Gestão do conhecimento 

• Sistema de conhecimento. 

• Informação de mercado. 

• Lições aprendidas. 

Gestão de ameaças 

• Gestão do risco organizacional. 

Análise de oportunidades de sourcing 

• Definição da situação atual. 

• Critérios de sourcing. 

Abordagem de sourcing 

• Análise de risco e impacto. 

Avaliação do fornecedor de serviço 

• Guias de negociação. 

Transferência de serviços 

• Transição do serviço. 

• Projeto de verificação. 

Gestão dos serviços contratados 

• Feedback dos interessados relevantes. 

• Análise do valor dos serviços. 

Encerramento do sourcing 

• Continuidade do serviço. 

Nível 4 

Gestão do relacionamento 

• Relacionamentos colaborativos. 

• Relacionamentos inovativos. 

Gestão do valor 

• Basetines de capacidade. 

• Processos de benchmarking de sourcing. 

• Inovação. 

• Valor e impacto no negócio. 

• Alinhamento do sourcing. 

Gestão do conhecimento 

• Compartilhamento do conhecimento. 


Tabela 11.4- Práticas por níveis de capacidade 
Adaptado de Hefley & Loesche (2006) 
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11 . 2.4 Aplicabilidade do modelo 

O eSCM-CL aplica-se à contratação dos seguintes tipos de serviços: 

□ Serviços de engenharia. 

□ Captura de dados. 

□ Centrais de serviços. 

□ Compras. 

□ Recursos humanos. 

□ Serviços financeiros e contabilidade. 

□ Application Services provider. 

□ Data centers. 

□ Manutenção de computadores. 

□ Desenvolvimento e gestão de aplicações. 

□ Suporte de redes e telecomunicações. 

11 . 2.5 Benefícios do modelo 

Os principais benefícios com a adoção do modelo são: 

□ Estabelecer e manter a confiança com todos os interessados relevantes. 

□ Comunicar-se efetivamente com todos os interessados relevantes. 

□ Aumentar a capacidade e a velocidade de lidar com as mudanças do 
negócio. 

□ Gerenciar os riscos de sourcing de forma efetiva. 

□ Implementar controles efetivos. 

□ Prover a melhoria contínua do processo e do desempenho. 

□ Possibilitar à organização focar no seu negócio principal. 

□ Construir e manter a competência pela gestão do sourcing. 

□ Melhorar a governança do sourcing. 

□ Melhorar as capacidades gerenciais do relacionamento e das parcerias. 

□ Tomar ações apoiadas por medições. 


11 . 2.6 Certificações relacionadas 

A organização cliente também pode obter uma certificação da sua aplica¬ 
ção do eSCM-CL, analogamente ao que ocorre no eSCM-SP. 
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11.3 CM MI for Acquisition 

O CMMI-ACQ tem o propósito de ser um guia para a implantação das 
melhores práticas do CMMI para organizações compradoras de serviços, 
sendo que essas melhores práticas estáo focadas nas atividades para adqui¬ 
rir produtos e serviços para atender às necessidades dos clientes e usuários 
finais. 

Este modelo, em sua versáo 1.3, de novembro de 2010, exibe a mesma es¬ 
trutura do CMMIModelFoundation (CMF), adotando o mesmo esquema de 
certificação, de maturidade e capacidade. Foi desenvolvido levando em con¬ 
sideração melhores práticas governamentais e de empresas privadas e contou 
com a colaboração de vários profissionais ao redor do mundo. 

O CMMI-ACQ é composto por 22 áreas de processos específicos e um 
conjunto de práticas genéricas alocadas conforme os níveis de maturidade 
da representação por estágios e compartilha de algumas áreas de processo co¬ 
muns ao CMF. 

Para esse modelo, o termo Projeto significa “Projetos de Aquisição”. 

As tabelas 11.5, 11.6, 11.7 e 11.8 apresentam uma breve descrição de cada 
uma das áreas de processo, conforme os níveis de maturidade. 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 2 

Gestão de contratos (AM) 

Assegurar que o fornecedor e o adquirente se comportem de 
acordo com o contrato de fornecimento. 


Desenvolvimento dos 
requisitos da aquisição (ARD) 

Elicitar, desenvolver e analisar os requisitos do cliente e os 
contratuais. 


Gestão da configuração (CM) 

Estabelecer e manter a integridade dos produtos de 
trabalho usando a identificação de configuração, controle da 
configuração, o status da configuração e as auditorias de 
configuração. 


Medição e análise (MA) 

Desenvolver e sustentar uma capacidade de medição usada 
para apoiar as necessidades de informações gerenciais. 


Controle e monitoração do 
projeto (PMC) 

Fornecer um entendimento do progresso do projeto de 
forma que ações corretivas podem ser tomadas quando o 
desempenho desvia significativamente do plano. 


Planejamento do projeto (PP) 

Estabelecer e manter planos para definir as atividades do 
projeto. 
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Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 2 

Garantia da qualidade do 
processo e do produto 
(PPQA) 

Fornecer ao pessoal de serviços e à gerência avaliações 
objetivas acerca dos processos e dos produtos de trabalho 
associados. 

Gestão de requisitos (RM) 

Gerenciar os requisitos dos produtos e dos componentes 
dos produtos do projeto e assegurar o alinhamento entre 
eles e os requisitos dos planos e produtos do projeto. 

Solicitação e desenvolvimento 
do acordo com o fornecedor 
(SSAD) 

Preparar o pacote de solicitação, selecionar um ou 
mais fornecedores para entregar o produto ou serviço e 
estabelecer e manter o contrato. 


Tabela 11.5 - CMMI-ACQ - Processos do nível 2 
Adaptado de SEI (2010a) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 3 

Gestão da aquisição técnica 
(ATM) 

Avaliar a solução técnica do fornecedor e gerenciar as 
interfaces da solução. 


Validação da aquisição 
(AVAL) 

Demonstrar que um produto ou serviço adquirido preenche o 
seu uso pretendido quando colocado no ambiente intencionado. 


Verificação da aquisição 
(AVER) 

Assegurar que os produtos de trabalho atendem às suas 
especificações. 


Análise e resolução de 
decisão (DAR) 

Analisar possíveis decisões usando um processo formal 
de avaliação que analisa alternativas identificadas contra 
critérios estabelecidos. 


Gestão integrada do projeto 
(IPM) 

Estabelecer e gerenciar o projeto e o envolvimento de 
interessados relevantes de acordo com processos definidos 
e integrados que são “customizáveis” a partir do conjunto 
padrão de processos. 


Definição do processo 
organizacional (OPD) 

Estabelecer e manter um conjunto de ativos de processos 
organizacionais, padrões do ambiente de trabalho, regras e 
guias de orientação para as equipes. 


Foco no processo 
organizacional (OPF) 

Planejar, implementar e entregar melhorias nos processos 
organizacionais com base no completo entendimento dos 
pontos fortes e fracos dos processos e ativos de processos 
da organização. 


Treinamento organizacional 
(OT) 

Desenvolver habilidades e conhecimentos de pessoas, de 
forma que possam desempenhar seus papéis de maneira 
efetiva e eficaz. 
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Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 3 

Gestão de riscos (RSKM) 

Identificar os problemas potenciais antes que eles ocorram, 
de forma que as atividades de riscos possam ser planejadas 
e acionadas quando necessário ao longo do ciclo de vida 
do produto ou trabalho, para mitigar impactos adversos no 
atendimento aos objetivos. 


Tabela 11.6 - CMMI-ACQ - Processos do nível 3 
Adaptado de SEI (2010a) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 4 

Desempenho do processo 
organizacional (OPP) 

Estabelecer e manter um entendimento quantitativo 
do desempenho de processos selecionados, no 
conjunto de processos da organização, em apoio 
ao atendimento dos objetivos de qualidade e 
de desempenho do processo e fornecer dados 
de desempenho, baselines e modelos para, 
quantitativamente, gerenciar os projetos. 

Gestão quantitativa do projeto 
(QPM) 

Gerenciar quantitativamente o projeto para atender 
aos objetivos de qualidade e desempenho do processo 
estabelecido para o projeto. 


Tabela 11.7 - CMMI-ACQ - Processos do nível 4 
Adaptado de SEI (2010a) 


Nível de 

Maturidade 

Área de Processo 

Descrição 

Nível 5 

Gestão do desempenho 
organizacional (OPM) 

Gerenciar proativamente o desempenho da organização 
para atender aos objetivos do negócio. 

Análise e resolução de causas 
(CAR) 

Identificar causas de resultados selecionados e tomar 
ações para melhorar o desempenho do processo. 


Tabela 11.8 - CMMI-ACQ - Processos do nível 5 
Adaptado de SEI (2010a) 


Os principais benefícios do CMMI-ACQ podem ser distribuídos pelos es¬ 
tágios de maturidade atingidos por uma organização compradora de produtos 
e serviços, como mostra a Tabela 11.9. 
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Nível de Maturidade 

Benefícios 

2 - Gerenciado 

• 0 projeto é gerenciado e entregue conforme o planejado. 

• As aquisições atendem aos requisitos do cliente. 

• Os acordos com os fornecedores são gerenciados. 

• 0 provedor de serviços adquire a capacidade de medir o desempenho do 
serviço. 

• Recursos estão disponíveis para a execução do projeto de aquisição. 

• Os processos são mantidos em períodos de pico de demanda. 

3 - Definido 

• 0 adquirente emprega processos definidos. 

• As aquisições são validadas e verificadas para atender aos requisitos e 
especificações. 

• Os processos são melhorados continuamente. 

• Processos podem ser adaptados para atender a situações específicas. 

• Ganhos de produtividade à medida que os ativos de processos são 
gerenciados. 

4 - Gerenciado 
Quantitativamente 

• Os processos são gerenciados a partir de objetivos de desempenho. 

• A qualidade e o desempenho do processo são entendidos de forma estatística. 

• 0 desempenho do processo é entendido e previsível. 

• A capacidade do processo é compreendida. 

5 - Otimizado 

• Os processos são melhorados continuamente com o entendimento dos 
objetivos do negócio e as necessidades de desempenho. 

• A organização compreende as causas de variação nos processos. 

• Os processos são melhorados continuamente e através de inovações. 

• Os resultados das melhorias são analisados quanto ao seu efeito no 
desempenho do processo. 

• 0 foco é sobre a melhoria da organização como um todo. 


Tabela 11.9 - Benefícios do CMM-ACQ 

Adaptado de SEI (2010a) 


Esse modelo pode ser de grande valia para organizações que realizam, de 
forma contínua, aquisições de produtos e serviços de alta complexidade. En¬ 
tretanto, acreditamos que dificilmente uma organização, pelo menos no Bra¬ 
sil, tente ser avaliada formalmente em relação ao CMMI-ACQ. 

Contudo, este modelo pode ser usado, assim como o eSCM-CL, como 
benchmarking para a melhoria de seus processos de aquisição. 











Modelos para Disciplinas 
Complementare s à Governança de TI 

12.1 BPM CBOK® 

12 . 1.1 Histórico do modelo 

A ABPMP (Associação de Profissionais de Gerenciamento de Processos 
de Negócio 96 ) é uma organização profissional sem fins lucrativos, indepen¬ 
dente de fornecedores, orientada e conduzida por profissionais, dedicada ao 
desenvolvimento dos conceitos de gerenciamento de processos de negócio 
e suas práticas. A ABPMP foi fundada em 2003, está sediada nos Estados 
Unidos e possui capítulos distribuídos por todo o mundo, inclusive no Bra¬ 
sil, desde março de 2008 (maiores informações podem ser obtidas no site 
www.abpmp-br.org). 

Tendo em vista que existe um corpo de conhecimento bastante vasto acer¬ 
ca do assunto BPM (Gerenciamento de Processos de Negócio 97 ), a ABPMP 
projetou o BPM CBOK®, denominado “Guia para o Corpo Comum de Co¬ 
nhecimentos sobre BPM”, que abrange questões, melhores práticas e lições 
aprendidas normalmente praticadas pelas organizações e visa auxiliar os pro¬ 
fissionais de BPM em seu trabalho. 

A primeira versão do BPM CBOK® foi publicada em fevereiro de 2008, 
e a versão 1.1 veio logo em seguida, em maio de 2008. A versão 2.0 foi 
liberada em fevereiro de 2009, assimilando várias atualizações baseadas em 
sugestões e contribuições dos profissionais da comunidade de BPM em todo 
o mundo. 


96 Em inglês: Association of Business Process Management Professionals. 

97 Em inglês: Business Process Management. 
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Em 2011, o Comitê Gestor da ABPMP International promoveu o início 
de um trabalho de atualização do modelo, tendo em mente diretrizes tais 
como fomentar o uso de uma linguagem comum para BPM (para uniformi¬ 
zar o entendimento), ser isento de “marcas” (fornecedores, metodologias, fer¬ 
ramentas), visualizar nele um guia contendo práticas comprovadas e aceitas e 
focando conceitos atuais (referenciando inclusive outras disciplinas) e garantir 
a relevância e a clareza do seu conteúdo. O resultado desse trabalho, que teve 
uma participação significativa de profissionais do mercado brasileiro de BPM, 
foi a versão 3.0, publicada em 2013. 


12 . 1.2 Objetivos do modelo 

De acordo com ABPMP (2013), o BPM CBOK® tem como finalidade 
principal identificar e fornecer uma visão geral das áreas de conhecimento 
necessárias para a prática de BPM. Nesse sentido, apresenta uma visão geral, 
uma lista de tópicos, links e referências comuns associados, além de tarefas 
específicas para cada área de conhecimento. 

Adicionalmente, o BPM CBOK® propõe um glossário para incentivar o 
uso de uma terminologia padronizada e sugere um modelo curricular para a 
disciplina de BPM, aplicável a qualquer certificação profissional ou avaliação 
na área. Esse guia consiste na base para o desenvolvimento das questões do 
exame “CBPP™ - Profissional Certificado em Processos de Negócio” 98 , que 
será abordado mais adiante nesta seção. 


12 . 1.3 Estrutura do modelo 

O BPM CBOK® está organizado em nove áreas de conhecimento (cada 
uma delas descrita em um capítulo), conforme mostra a Figura 12.1. 
Cada uma das áreas de conhecimento será brevemente explorada nas seções 
seguintes. 


98 Em inglês: Certified Business Process Professional. 
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Perspectiva Organizacional 


Gerenciamento Corporativo de Processos 
Organização do Gerenciamento de Processos 


Perspectiva de Processo 


Gerenciamento de Processos de Negócio 
Modelagem de Processos 
Análise de Processos 
Desenho de Processos 

Gerenciamento de Desempenho de Processos 
Transformação de Processos 
Tecnologias de BPM 


Figura 12.1 - A organização do BPM CBOK ( 
Fonte: ABPMP(2013) 


12.1.3.1 Gerenciamento de Processos de Negócio 

De acordo com a ABPMP (2013), esta área de conhecimento define BPM 
como “uma disciplina gerencial que integra estratégias e objetivos de uma 
organização com expectativas e necessidades dos clientes, por meio do foco 
em processos ponta a ponta”, que visa gerar valor aos clientes. BPM é uma 
abordagem disciplinada para identificar, desenhar, executar, documentar, me¬ 
dir, monitorar e melhorar processos de negócio, a fim de atingir resultados 
consistentes com metas estratégicas da organização. BPM não deve ser visto 
como uma prescrição de metodologias, ferramentas ou estruturas de trabalho, 
mas sim como uma abordagem que prevê a utilização combinada de várias 
delas, conforme as necessidades de cada organização. 
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Nesta área, são definidos conceitos e princípios importantes de BPM, tais 
como: 

□ Processo : conjunto definido de atividades ou comportamentos reali¬ 
zados por humanos ou máquinas, para atingir uma ou mais metas. 
Processos podem ser primários" (permeiam as funções da organiza¬ 
ção e compõem a cadeia de valor), de suporte (que habilitam os de¬ 
mais processos) e de gerenciamento (utilizados para medir, monitorar 
e controlar atividades de negócio, além de garantir que os demais 
processos atinjam suas metas operacionais, financeiras, regulatórias 
e legais). 

□ Orquestração : processos de negócio subdividem-se em subprocessos, 
que sáo realizados por uma ou mais atividades (fluxos de trabalho) 
dentro de funções de negócio (áreas funcionais). As atividades, po¬ 
dem ser decompostas em tarefas e estas em cenários de realização com 
seus respectivos passos. Em todos esses níveis, o gerenciamento pode 
envolver indicadores de desempenho de processos 100 significativos, 
que permitem comparações em termos de tempo, custo, capacidade 
e qualidade. 

□ Dimensões para Entendimento dos Processos : visando promover um 
melhor entendimento e visualização dos processos, BPM busca de¬ 
finir, de maneira abrangente, “o que”, “onde”, “quando”, “por que”, 
“como” e “por quem” o trabalho é realizado dentro deles. 

□ Ciclo de Vida de BPM : caracteriza a prática gerencial de BPM como 
um ciclo contínuo formado por etapas tais como Planejamento, Aná¬ 
lise, Desenho, Implementação, Monitoramento e Controle, Refina¬ 
mento 101 . Ao longo deste ciclo, os processos sofrem influência (ha- 
bilitadora ou restritiva) de fatores tais como organização, definição 
de processos, responsabilidade, patrocínio, medição, sensibilização 
das pessoas, alinhamento dos processos com a estratégia, tecnologia 
da informação e metodologia para iniciativas BPM, além de valores, 
crenças, liderança e cultura existentes na organização. 


99 Em algumas literaturas, tais processos são denominados “finalísticos”, por estarem diretamente 
relacionados com a finalidade da organização. 

100 PPIs ( Process Performance Indicators). 

101 Assim como neste exemplo (sequência de etapas), é possível mapear a maioria dos ciclos de vida 
na forma de um ciclo PDCA básico. 
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□ Características de BPM : envolve processos de negócio “ponta a pon¬ 
ta” que criam valor para a organização e a habilitam a atingir seus 
objetivos com maior facilidade, cada vez mais suportada pela tecno¬ 
logia, tendo nos controles operacionais e financeiros a garantia de que 
os processos estão sendo eficientes e eficazes. 

Esta área de conhecimento fornece os fundamentos básicos para o entendi¬ 
mento e o estudo das demais áreas de conhecimento do BPM CBOK®. 


12.1.3.2 Modelagem de Processos 

Esta área de conhecimento fornece uma visão geral da modelagem de proces¬ 
sos, em termos de sua finalidade, dos seus benefícios, assim como de técnicas, 
ferramentas, padrões, atividades e habilidades necessárias para a sua realização. 

Modelos de processos são representações simplificadas de uma atividade 
ou de um conjunto de atividades de negócio e servem para documentar, ana¬ 
lisar ou comunicar diversos aspectos de um processo de negócio, em níveis 
de detalhamento variados, visando criar uma representação dos processos de 
maneira completa e precisa sobre seu funcionamento. 

Nesta área, são abordados aspectos importantes da modelagem de proces¬ 
sos, tais como: 

□ Características dos modelos de processos : são discutidas algumas pro¬ 
priedades acerca das formas possíveis para os modelos de processos, 
assim como as características de seus principais componentes. 

□ Padrões e notações de modelagem : são apresentados, brevemente, 
padrões e notações tais como BPMN ( Business Process Modeling No- 
tation), fluxogramas, ePC [Event Process Chain), VSM ( Value Stream 
Mapping ), UML ( Unified Modeling Language) , IDEF etc. 

□ Abordagens especializadas para modelos : um modelo de processo 
deve ter detalhamento suficiente para explicar o ambiente de negó¬ 
cio, a estrutura organizacional, a forma como as funções/departa- 
mentos trabalham em conjunto no processo, as regras de negócio, 
as atividades e seus executores. Nesse sentido, o BPM CBOK® faz 
referências a abordagens como cadeia de valor, SIPOC e dinâmica 
de sistemas. 
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□ Perspectivas de modelagem : os modelos de processos devem ser capa¬ 
zes de integrar as diferentes perspectivas que compõem a arquitetura 
da organização (por exemplo, corporativa, negócios, operações/fluxos 
de trabalho, desenho de sistemas, dos construtores e operadores dos 
sistemas) e seus respectivos tipos específicos de modelos e níveis de 
detalhamento. Essa estrutura de modelos, em geral, é mantida em um 
repositório de processos. 

□ Níveis de detalhe na modelagem : da mesma forma, deve haver mo¬ 
delos que representem os vários níveis da organização (por exemplo: 
cadeia de valor no nível corporativo, modelos de processos no nível 
do negócio, modelos de atividades no nível operacional, modelos de 
tarefas no nível do fluxo de trabalho e assim por diante). Tais modelos 
devem ser capazes de responder perguntas como “o que”, “como”, 
“onde”, “por que”, “quando” e “por quem”, relacionadas ao processo 
em questão. 

São também abordadas nesta área de conhecimento técnicas e ferramentas 
úteis na captura de informações para modelagem de processos. 


12.1.3.3 Análise de Processos 

Esta área de conhecimento está relacionada à obtenção de um entendi¬ 
mento comum acerca da realidade atual de um processo e do grau em que este 
está atendendo aos objetivos da organização, dentro do ambiente atual dos 
negócios (visão conhecida como Af Is). A análise de um processo pode ocorrer 
a qualquer momento (reativamente), embora seja mais adequada uma atitude 
proativa e/ou continuada na monitoração dos processos, antes que eventos 
indesejados aconteçam e disparem uma análise. 

Um dos objetos da análise de processos é a identificação de pontos de aten¬ 
ção no processo tais como objetivos de desempenho não alcançados, falhas 
nas interações com o cliente, passagens de responsabilidade que geram desco¬ 
nexões, variações de processo e gargalos, com a utilização de metodologias e 
técnicas específicas. 

Os resultados obtidos com a análise de um processo devem ser validados 
junto a todos os que interagem com o processo e representar efetivamente o 
que está acontecendo, e não aquilo que se deseja que aconteça, em uma visão 





Modelos para Disciplinas Complementares à Governança de TI 451 


totalmente imparcial e isenta de culpas. Um bom produto da análise certa¬ 
mente será de muita valia para quem irá conduzir o desenho do processo (a 
seguir no ciclo de vida). 

Nesta área de conhecimento, são feitas ainda considerações sobre técnicas, 
ferramentas, fatores-chave de sucesso, práticas sugeridas e riscos que fazem 
parte do contexto de uma análise de processo. 


12.1.3.4 Desenho de Processos 

Desenhar um processo significa criar um novo processo (ou um processo 
modificado) para atender às metas de negócio e aos objetivos de desempenho 
da organização (visáo conhecida como To Be). Tais atividades devem envolver 
a liderança executiva da empresa, o(s) dono(s) do processo e as principais par¬ 
tes interessadas (na concepção e criaçáo do processo), além de especialistas no 
assunto (para a equipe de desenho do processo). 

De acordo com ABPMP (2013), as atividades relacionadas ao desenho de 
processos incluem: utilizar ferramentas de modelagem para o desenho, definir 
as atividades/tarefas e as regras de negócio para o novo processo, definir a for¬ 
ma como as responsabilidades seráo transferidas entre as atividades ( bandoffs ), 
definir as métricas para o processo, realizar comparações e benchmarkings com 
outros processos e organizações, realizar simulações e testes e criar um plano 
para implementação do processo novo. O desenho de processos deve consi¬ 
derar o nível de fluxo de processo (visáo interfuncional) e o nível de fluxo de 
trabalho (visáo intrafuncional), de forma que o resultado final seja balanceado 
em todos os níveis, em termos de eficácia e eficiência. 

Recomenda-se ainda que o desenho de processos aconteça náo na forma 
de um evento isolado, mas sim dentro de um programa de melhoria contínua 
de processos. 

Nesta área de conhecimento, sáo feitas ainda considerações sobre papéis e 
responsabilidades, atividades-chave, princípios e boas práticas sugeridas, que 
fazem parte do contexto de um desenho de processo (inclusive considerando 
temas atuais, tais como desenho de serviços, terceirização de processos 102 e 
serviços compartilhados). Além disso, o BPM CBOK® discute alguns fatores- 
-chave de sucesso que, se náo observados no tempo certo, podem se tornar 


102 Dentro do contexto conhecido como BPO (Business Process Outsourcing). 
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“pedras no sapato” para o sucesso da fase de desenho do processo (liderança 
executiva, propriedade do processo, incentivos e recompensas, equipes in- 
terfuncionais, melhoria contínua, compromisso com o seu investimento e 
alinhamento/integraçáo com a estratégia da organização). 


12.1.3.5 Gerenciamento de Desempenho de Processos 

Para esta área de conhecimento, todos os processos são mensuráveis a par¬ 
tir do trabalho executado ou das saídas produzidas, e qualquer métrica ou 
indicador de processo (mesmo aqueles que medem a eficácia ou a eficiência) 
é uma fimçáo que combina quatro dimensões fundamentais: tempo, custo, 
capacidade e qualidade. 

Medir um processo é uma atividade fundamental para o seu controle e 
gerenciamento, que gera importantes subsídios para a tomada de decisões 
por parte dos gestores e donos de processo, visando atender aos objetivos 
estratégicos da organização. As medições podem ser coletadas, analisadas e 
reportadas manualmente ou por meio de ferramentas sofisticadas de software 
(inclusive os da categoria BPMS). 

Esta área de conhecimento abrange conceitos relativos ao desempenho de 
processos, considerações sobre a importância e os benefícios de medir o de¬ 
sempenho dos processos, requisitos básicos para indicadores de desempenho 
de processos (PPIs) eficazes e também características de métodos de mediçáo, 
modelagem e simulação. 

Segundo ABPMP (2013), focar nos processos e nas pessoas, entender todo 
o processo (fim a fim) em vez de somente as tarefas individuais, entender 
como o processo está associado a métricas de desempenho operacional e ali¬ 
nhado com mecanismos de compensação por resultados e garantir que as ati¬ 
vidades sejam desenhadas e aprovadas por quem as executa são fatores críticos 
de sucesso para o gerenciamento do desempenho dos processos. 


12.1.3.6 Transformação de Processos 

Transformar processos significa, efetivamente, implementar processos no¬ 
vos ou modificados em uma organização. Em outras palavras, significa pla¬ 
nejar a evolução dos processos, gerenciar os riscos e problemas decorrentes, 
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“construir”, controlar a qualidade, instalar os artefatos que representam essa 
evolução (especificações, descrições de procedimentos, regras de negócio, 
componentes/sistemas automatizados etc.) e treinar os executores do proces¬ 
so. De acordo com a ABPMP (2013), a transformação de processos apresenta 
uma amplitude de impacto que inclui iniciativas de melhoria contínua, rede¬ 
senho, reengenharia e mudança de paradigma, que devem ser conduzidas por 
um método de trabalho consistente e evolutivo. 

Além de todas as atividades de implementação mencionadas, esta área de 
conhecimento reforça a importância do gerenciamento da mudança organi¬ 
zacional , em todos os seus aspectos. Recomenda-se que toda iniciativa de 
melhoria de processos necessariamente esteja relacionada a um programa de 
melhoria contínua, que contemple a mudança organizacional desde a estraté¬ 
gia até as tarefas individuais e que o gerenciamento de mudança formal seja 
visto como um portfólio de ferramentas a ser utilizado de forma flexível para 
iniciativas de graus variados. 

E importante também que, após a implementação dos processos de negó¬ 
cio, os benefícios obtidos sejam avaliados por meio de análise das estatísticas 
de desempenho operacional e financeiro, coletadas a partir dos dados de de¬ 
sempenho do BPM. 

Esta área de conhecimento menciona modelos como Seis Sigma, Leem etc., 
como metodologias de melhoria que podem ser empregadas no contexto da 
transformação de processos. Adicionalmente, uma vez que cada iniciativa de 
transformação de processos usualmente é conduzida na forma de um projeto, 
ressalta a importância de seguir uma metodologia de gerenciamento de proje¬ 
tos, como, por exemplo, a proposta no PMBOK 103 . 


12.1.3.7 Organização do Gerenciamento de Processos 

De acordo com a ABPMP (2013), “conforme uma organização amadurece 
no gerenciamento dos seus processos de negócio, sua estrutura organizacio¬ 
nal tenderá naturalmente em direção a uma mudança que compreenda uma 
dimensão de processo”. Isso quer dizer que, à medida que uma organização 
vai adquirindo uma cultura de processo 104 , novos papéis e estruturas organiza- 

103 Ver Capítulo 9 deste livro. 

104 Segundo a ABPMP (2013), a “cultura de processo” é um conceito em que os processos de negócio 
são conhecidos, acordados, comunicados e visíveis a todos os colaboradores da organização. 
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cionais podem surgir para viabilizar uma estrutura de governança que forneça 
liderança e torne claros os direitos de tomada de decisão, de forma a permitir 
que programas de melhoria ou gerenciamento de processos departamentais 
ou interfuncionais sejam bem-sucedidos. 

Nesse contexto, esta área de conhecimento define alguns novos papéis e 
estruturas organizacionais cujo foco é a atuação de forma transversal (através 
das estruturas funcionais) nas organizações, de forma a facilitar e tornar mais 
efetivo o gerenciamento dos seus processos primários de negócio. 

Entre os papéis propostos, um dos mais relevantes é o do Dono do Pro¬ 
cesso, cuja responsabilidade é “garantir e prestar contas pelo sucesso do de¬ 
senho, do desenvolvimento, da execução e da realização de um processo de 
negócio completo, de ponta a ponta”. Este papel deve também prestar contas 
acerca do desempenho do processo e atuar como um defensor do seu proces¬ 
so junto às demais áreas da organização. Além desse papel, são definidos os 
papéis de Gerente, Analista, Designer e Arquiteto de Processos. 

Entre as estruturas organizacionais mencionadas, figuram: 

□ Conselho de BPM : reúne líderes executivos e funcionais, além dos 
donos dos principais processos, com a missão de resolver questões de 
integração entre processos, de conflitos entre lideranças de processos 
e lideranças funcionais, de alocação de recursos e de alinhamento 
estratégico, por exemplo. 

□ Comitê de Processos : reúne o gerente de processos e gestores funcio¬ 
nais envolvidos, com a missão de, entre outras questões, se respon¬ 
sabilizar por avaliar o desempenho do atendimento dos SLAs e as 
melhorias nos processos e áreas funcionais individuais. 

□ Escritório de Processos : equipes que podem atuar como suporte aos 
projetos de processos de negócio, além de definir padrões, métodos e 
ferramentas comuns, treinar e educar os colaboradores nos princípios 
e nas práticas de BPM, atuar como um centro de governança, man¬ 
ter o repositório de processos atualizado, colaborar na integração dos 
processos de negócio corporativos etc. 

□ Centros de Excelência Funcionais : grupos de melhores práticas que 
fornecem conhecimento, padrões, melhores práticas, treinamento e 
educação (especializados) acerca das atribuições de um determinado 
grupo funcional em um processo de negócio. 
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12.1.3.8 Gerenciamento Corporativo de Processos 

De acordo com a ABPMP (2013), o Gerenciamento Corporativo de 
Processos é uma prática gerencial essencial que fornece meios para uma 
organização criar valor para seus clientes. Nesse sentido, garante que o 
portfólio de processos de negócio “ponta a ponta” e a arquitetura de pro¬ 
cessos estejam alinhados com a estratégia de negócio da organização e com 
a alocação dos recursos. Esta disciplina envolve a transição da estratégia 
de negócio em processos interfuncionais, cujos objetivos e resultados pre¬ 
cisam ser medidos e comunicados apropriadamente para toda a empresa. 
Para que exista uma governança de processos bem-sucedida, é necessário 
que os processos tenham regras claras de propriedade e responsabilidades 
pela prestação de contas. 

Para tal, esta área de conhecimento estabelece três requisitos essenciais: 

□ Estrutura de trabalho de medição centrada no cliente : estabelecer 
métricas que focam o que realmente importa para os clientes e que 
abordem os processos de forma holística, podendo incluir medições 
de qualidade, oportunidade, inteireza, precisão e capacidade de res¬ 
posta dos produtos e serviços fornecidos. 

□ Gerenciamento do portfólio de processos : o portfólio de processos 
permite uma visão dos processos por uma perspectiva de integração e 
de priorização de investimentos. Este requisito é um componente es¬ 
sencial de governança e permite avaliar e gerenciar todos os processos 
da organização de forma consolidada. 

□ Plano de gerenciamento e melhoria de processos : criação de um pla¬ 
no que identifique claramente o escopo da melhoria de processos, 
a prioridade relativa e a responsabilidade pelas ações. Envolve tam¬ 
bém a comunicação a todos os envolvidos, de forma a uniformizar o 
conhecimento. 

O foco nesta área de conhecimento pode auxiliar uma organização a 
enxergar o valor real das iniciativas de BPM, pois envolve avaliações es¬ 
tratégicas dos processos em alto nível e avaliações de desempenho. Dessa 
forma, constitui-se em uma poderosa ferramenta para justificar (ou não) o 
engajamento da organização em iniciativas de BPM, a partir da perspectiva 
dos clientes. 
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Esta área de conhecimento faz menção a diversos frameworks de melhores 
práticas relativas a processos, tais como o SCOR ( Supply Chain Operational 
Reference model ), a estrutura de classificação de processos da APQC ( American 
Productivity and Quality Councit) etc., como fontes de informação e, even¬ 
tualmente, de modelos para customização de processos para as organizações 
clientes. Adicionalmente, discute a utilização de níveis de maturidade para o 
gerenciamento de processos de negócio, sugerindo questionamentos para que 
as organizações façam uma autoavaliação de maturidade. 


12.1.3.9 Tecnologias de BPM 

Esta área de conhecimento aborda as características dos sistemas compu¬ 
tacionais disponíveis atualmente que fornecem suporte aos profissionais de 
BPM no planejamento, na modelagem, no desenho, na análise, na operação, 
no monitoramento e controle, na avaliação do desempenho e na orquestração 
dos processos de negócio. Tais sistemas são conhecidos como BPMS 105 (Siste¬ 
mas ou Suítes de Gerenciamento de Processos de Negócio). 

De acordo com a ABPMP (2013), os BPMSs podem abranger vários tipos 
de tecnologias, que foram originalmente idealizadas para necessidades espe¬ 
cíficas. A Tabela 12.1 mostra a relação de algumas dessas tecnologias com as 
atividades de BPM que suportam: 


Atividades de BPM 
Suportadas 

Tipos de Tecnologia 

Características 

Modelagem, Análise e 
Desenho 106 

Ferramentas para 
modelagem 

Permitem criar diagramas, mapas e modelos de 
processos, utilizando símbolos como representação, 
podendo, em alguns casos, armazenar dados acerca de 
cada componente do processo (dicionário de dados). 

A notação BPMN (Business Process Modeling Notation) 
tem sido cada vez mais utilizada como padrão para a 
descrição de processos, embora outras notações, tais como 
fluxogramas, ePC, IDEF etc. também sejam utilizadas. 


105 Em inglês: Business Process Management Systems/Suites. 

106 Ferramentas de modelagem e simulação situam-se no rol das tecnologias de BPA (Business Process 
An a lysis). 
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Atividades de BPM 
Suportadas 

Tipos de Tecnologia 

Características 


Ferramentas para 
simulação 

Simulam os passos e as ações do processo a partir de 
iterações de um evento inicial, com base em alguns 
pressupostos, estabelecendo pontos para medição 
de indicadores operacionais (tais como custo, tempo, 
esforço, capacidade, qualidade, etc.). 


Ferramentas de 

Arquitetura Empresarial 107 

Permitem a modelagem e a análise da estrutura da 
organização, de forma que ela possa cumprir com os 
requisitos atuais e futuros do negócio. Seus modelos 
englobam perspectivas de negócios, dados, aplicações 
e tecnologia. 


Gerenciamento Eletrônico 
de Documentos (GED)/ 
Gerenciamento de 
Conteúdo Empresarial 
(ECM) 

Capturam, organizam e fornecem informações 
necessárias para a execução de cada passo no 
processo. 

Como as características desses sistemas têm 
evoluído para incluir qualquer conteúdo eletrônico 
(digitalizado por um scanner ou criado por aplicações 
diversas), o uso do termo ECMS 108 (Sistemas de 
Gerenciamento de Conteúdo Empresarial) tem se 
tornado muito popular. 

Implementação e 

Gerenciamento de regras 
de negócio 109 

Suportam a identificação, a definição, o 
armazenamento, a garantia da qualidade e o acesso 
às regras de negócio que fazem parte da lógica do 
negócio da organização. 

Execução 

Formulários eletrônicos 

Utilizados para capturar, apresentar e distribuir 
informações. 

Podem utilizar padrões tais como XML (eXtensible 

Markup Languagé) para viabilizar o compartilhamento 
automatizado de dados entre aplicações. 


Gerenciamento de fluxos 
de trabalho ( workflows ) 

Possuem funcionalidades de caixas de entrada e 
de saída para cada papel e podem também possuir 
mecanismos de gerenciamento, administração, reporte 
e auditoria. 


Arquitetura Orientada a 
Serviço (SOA ) 110 

Permite a criação de serviços de negócio interoperáveis 
que podem ser reutilizados e compartilhados entre 
aplicativos. 


107 Os modelos de Arquitetura Empresarial geralmente seguem a abordagem da matriz de Zachman ou 
do TOGAF (abordado mais adiante neste capítulo). 

108 Em inglês: Enterprise Content Management Systems. 

109 Tais ferramentas, também denominadas “motores de regras”, pertencem à categoria de tecnologias 
de BRMS ( Business Rules Management Systems). 

110 O Capítulo 13 deste livro aborda a Governança SOA em maiores detalhes. 
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Atividades de BPM 
Suportadas 

Tipos de Tecnologia 

Características 


Enterprise Application 
Integration (EAI) 

Permitem a criação de adaptadores entre o meio 
de comunicação (barramento, por exemplo) e as 
aplicações 111 , auxiliando a implementar o protocolo e a 
visão de SOA. 


Colaboração em grupos 
de trabalho ( workgroups ) 

Coordenam e facilitam atividades em grupo por meio de 
vários serviços de aplicações (por exemplo: calendários, 
ferramentas de gerenciamento de projetos, sistemas 
de workflow que incluem várias áreas, fornecedores, 
clientes, acionistas etc.). 


Geração de aplicações 
para automação de 
processos 

Permitem a transformação de atividades dos processos 
em pequenas aplicações disponibilizadas aos atores 
responsáveis por sua execução. 


Gerenciamento de 
Metadados, 

Data Warehousing, 
Business Intelligence 

Extraem dados acerca da execução dos processos e 
os organizam, de forma a mostrar a cada público-alvo o 
nível adequado de informações gerenciais acerca dos 
processos de negócio. 


Monitoramento de 
Atividades de Negócio 112 

Fornecem uma visão abrangente de como o negócio 
está desempenhando as suas operações, permitindo 
ações corretivas para os problemas geralmente em 
tempo real. 

Decisões Gerenciais, 
Medições de 
Desempenho do 
Negócio e Atividades 
Administrativas 

BPMSs inteligentes 113 

Combinam análises de dados em tempo real, tecnologias 
de apoio à decisão para suportar cenários de negócio em 
que os processos de negócio precisam ser gerenciados 
com recursos adicionais de inteligência, face às 
tendências mais recentes sinalizadas pelo mercado (por 
exemplo, Big Data, tecnologias móveis, mídias sociais, 
computação em nuvem, etc.). 


Repositórios de processos 

São componentes fundamentais para o BPM, pois 
armazenam informações sobre processos, tais 
como propriedade, regras de negócio, habilitadores 
tecnológicos, controles financeiros e operacionais, etc. 

Em suma, armazenam informação sobre como uma 
organização opera através de seus processos. 


Tabela 12.1 - Atividades de BPM versus tipos de tecnologias 
Adaptado de ABPMP (2013) 


111 Tecnologia muito utilizada para integração com sistemas legados. 

112 Em inglês, BAM ou Business Activity Monitoring. 

113 Em inglês, iBPMS ou intelligent Business Process Management Suites. 
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12 . 1.4 Aplicabilidade do modelo 

Hoje em dia, é bastante improvável que ações de gerenciamento e melho¬ 
ria de processos de negócios, em organizações de todo tipo de tamanho, não 
estejam vinculadas a programas e projetos de TI. Dentro de um programa de 
BPM corporativo, podem constar vários tipos de iniciativas, tais como: 

□ Evoluçáo da arquitetura de TI da organização (por exemplo, adotan¬ 
do paradigmas como a arquitetura orientada a serviços - SOA). 

□ Implementaçáo/manutençáo de ferramentas BPMS como meio de 
orquestração dos processos e das interfaces com os sistemas legados, 
visando criar para a TI uma visáo dos processos primários (transver¬ 
sais) da organização e minimizar os pontos de interação manual entre 
os atores (pessoas e aplicações) que participam do processo. 

□ Projetos de manutenção adaptativa e/ou evolutiva nos sistemas 
legados. 

□ Iniciativas de desmaterialização de documentos físicos e de imple¬ 
mentação de uma cultura de gerenciamento do ciclo de vida dos do¬ 
cumentos, através da utilização de ferramentas de ECM (.Enterprise 
ContentManagement) e ILM (Information Lifecycle Management), in¬ 
tegradas à ferramenta BPMS. 

□ Criação de novas funções e estruturas organizacionais (tais como 
“donos” e gerentes de processos, Escritório de Processos, Comitê de 
Processos etc.), influenciando a estrutura de Governança de TI da 
organização. 

Como o BPM CBOK® consiste em um guia para todas as iniciativas de 
BPM em uma organização, abrangendo inclusive os programas e projetos de 
TI derivados, suas práticas e diretrizes podem ser utilizadas de forma combi¬ 
nada com vários outros modelos de melhores práticas de TI. 

Em relação à Governança de TI, o BPM CBOK® cumpre um papel muito 
importante, uma vez que contribui para que a disciplina de BPM esteja cada 
vez mais integrada com os processos e disciplinas da TI. Podemos identificar 
afinidades sutis (algumas vezes nítidas) entre as áreas de conhecimento do 
BPM CBOK® e os elementos de outros modelos já abordados neste livro, tais 
como mostra a Tabela 12.2: 
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Áreas de Conhecimento do 
BPM CBOK® 

Pontos de afinidade com outros modelos 

Gerenciamento de Processos de 
Negócio 

• ITIL: ciclo de vida de serviço. 

• CobiT: cobre a empresa de ponta a ponta. 

Modelagem de Processos 

• Metodologias de desenvolvimento de software: fase de análise. 

Análise de Processos 

• ITIL: Gerenciamento de Problemas. 

• Seis Sigma. 

• Metodologias de desenvolvimento de software: Fase de Análise. 

Desenho de Processos 

• ITIL: Desenho de Serviço. 

• ISO/IEC 20000: Desenho e transição de serviços novos ou 
modificados. 

• eSCM: fase de iniciação. 

• CobiT: domínio “Construir, Adquirir e Implementar” (BAI). 

• Metodologias de desenvolvimento de software: fases de projeto 
lógico e projeto físico. 

Gerenciamento do Desempenho de 
Processos 

• ITIL: Gerenciamento de Eventos, Medição de serviços. 

• ISO/IEC 20000: Relato de Serviço. 

• CMMI: área de processo “Medição e Análise”. 

• CobiT: domínio “Monitorar, Avaliar e Medir” (MEA). 

• Balanced Scorecard. 

Transformação de Processos 

• ITIL: Gerenciamento de Mudanças, Gerenciamento de Liberações. 

• PMBOK e PRINCE 2: todas as disciplinas e etapas da metodologia. 

• Seis Sigma. 

Organização do Gerenciamento de 
Processos 

• ITIL: Estratégia de Serviço. 

• ISO/IEC 20000: Desenho e transição de serviços novos ou 
modificados. 

• CobiT: domínio “Alinhar, Planejar e Organizar” (APO). 

• Modelo de Governança de TI: criação de novas estruturas 
organizacionais para apoiar o programa BPM. 

Gerenciamento Corporativo de 
Processos 

• Gerenciamento de Portfólio (PMI). 

• ITIL: Estratégia de Serviço (Gerenciamento de Portfólio de Serviços), 
Melhoria Continuada de Serviços. 

• CobiT: domínio “Avaliar, Dirigir e Monitorar” (EDM). 

• CMMI: base para o modelo de maturidade do BPM CBOK®. 

Tecnologias de BPM 

• CobiT: processo APO03 - Gerenciar a arquitetura corporativa, 
domínio “Construir, Adquirir e Implementar” (BAI). 


Tabela 12.2 - Pontos de afinidade entre o BPM CBOK® e os demais modelos de referência 

12 . 1.5 Benefícios do modelo 


Por ser um guia relativamente novo, no mercado ainda há poucos estudos 
de caso ou pesquisas específicas acerca da utilização do BPM CBOK®. Entre- 
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tanto, o modelo possui uma vasta gama de méritos que o posicionam como 
um potencial gerador de benefícios para todos os profissionais que, de forma 
direta ou indireta, estejam envolvidos em programas e iniciativas de BPM (e, 
consequentemente, para as organizações a que pertencem), tais como: 

□ É um guia que aborda os conceitos e princípios de BPM de forma 
bastante abrangente e independente de tecnologias, o que permite 
que seja utilizado em quaisquer organizações. 

□ Serve como base fundamental de conhecimentos para todo profissio¬ 
nal de BPM, ou seja, seu conteúdo é básico para qualquer avaliação 
ou certificação neste mercado. 

□ Apresenta um glossário que visa padronizar a terminologia relativa a 
BPM utilizada em todo o mundo, o que se constitui em um grande 
estímulo à universalização dos conhecimentos desta disciplina. 

□ Suas áreas de conhecimento cobrem todo o ciclo de vida de BPM, 
desde a concepção da primeira arquitetura de processos corporativos 
até o gerenciamento das iniciativas de melhoria de processos, sejam 
elas isoladas ou integrantes de um programa de melhoria contínua da 
organização. 

□ Sua abrangência na arquitetura empresarial vai desde a camada estra¬ 
tégica até a de implementação de sistemas de apoio, tratando de forma 
consistente as interfaces entre as camadas (processos, dados, sistemas). 


12 . 1.6 Certificações relacionadas 

A ABPMP possui um programa de certificação destinado a profissionais 
que têm o gerenciamento de processos de negócio como sua ocupação, ou que 
possuam longa experiência na área (no mínimo quatro anos de experiência 
profissional comprovada em trabalhos relacionados a BPM), o CBPP® ( Certi - 
fied Business Process Professional ). 

Através do CBPP®, o profissional demonstra sua prática, sua experiência 
e seu conhecimento nas nove áreas de conhecimento do BPM CBOK®. A 
preparação para o exame envolve o estudo do guia, a leitura da bibliografia 
recomendada, estudo individual e em grupo, participação em sessões de trei¬ 
namento e eventos (Boot Camps ) e, principalmente, a aplicação prática dos 
conceitos no trabalho do dia a dia. 
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A certificação tem validade por três anos, e a recertificação requer que o 
candidato se comprometa com um programa de educação continuada, cum¬ 
prindo uma quantidade mínima de horas em cada período. Maiores deta¬ 
lhes sobre a certificação CBPP® podem ser obtidos no site da ABPMP Brasil 
(www.abpmp-br.org). 


12.2 BABOK® 

12 . 2.1 Histórico do modelo 

O IIBA (Instituto Internacional de Análise de Negócios 114 ) é uma orga¬ 
nização canadense fundada em outubro de 2003 com o propósito principal 
de apoiar a comunidade de análise de negócios, por meio da conscientização 
e do reconhecimento do valor e da contribuição da profissão de Analista de 
Negócios, da criação de um fórum para promovê-la, da manutenção de um 
programa internacional de certificação direcionado a esses profissionais e da 
definição do “Corpo de Conhecimento de Análise de Negócios”, o BABOK®. 
O IIBA possui capítulos em todo o mundo e também no Brasil desde 2008 
(maiores informações no site www.theiiba.org.br). 

A versão 1.0 do Guia para o BABOK® foi liberada em janeiro de 2005 
para avaliação da comunidade de Análise de Negócios, com um sumário do 
conteúdo proposto e algumas definições-chave. A partir das proposições da 
comunidade, foram publicadas as versões 1.4 (outubro de 2005) e 1.6 (junho 
de 2006/outubro de 2008). A versão atual (2.0) foi publicada em 2009, após 
uma criteriosa revisão e a incorporação de sugestões de profissionais da comu¬ 
nidade e de especialistas de mercado. 


12 . 2.2 Objetivos do modelo 

Segundo o IIBA (2009), Análise de Negócios “é o conjunto de atividades 
e técnicas utilizadas para servir como ligação entre as partes interessadas, no 
intuito de compreender a estrutura, as políticas e as operações de uma orga¬ 
nização, e para recomendar soluções que permitam que a organização alcance 


114 Em inglês: International Institute of Business Analysis. 
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suas metas”. O Analista de Negócios é responsável por elicitar as necessidades 
reais das partes interessadas, e não simplesmente suas expectativas, e pode 
atuar como facilitador entre as unidades de negócio e a TL 

O principal objetivo do Guia para o BABOK® é servir como uma base de 
conhecimento para que os profissionais de Análise de Negócios possam com¬ 
preender seu papel, as habilidades necessárias e as tarefas que precisam realizar 
para adicionar valor a uma organização. 


12 . 2.3 Estrutura do modelo 

Um dos conceitos mais importantes para o BABOK® é o de requisito, em 
seu sentido mais amplo. Segundo o IIBA (2009), um requisito pode descrever 
a situaçáo atual ou futura de qualquer aspecto de uma organização e pode 
representar condições ou capacitações de uma empresa ou uma descrição de 
estrutura, processo, papel, política, regra ou sistema de informação. Um re¬ 
quisito pode ser classificado como: 

□ Requisito de Negócio (representa em alto nível um objetivo, meta ou 
necessidade da empresa). 

□ Requisito de Parte Interessada (representa uma necessidade de uma 
parte interessada em particular, ou de um conjunto delas). 

□ Requisito de Solução (pode ser funcional ou não funcional, descre¬ 
vendo uma característica de uma solução que atende a requisitos do 
negócio e/ou de uma parte interessada). 

□ Requisito de Transição (característica temporária de uma solução 
que pode auxiliar na transição da situação atual para uma situação 
futura). 

O Guia para o BABOK® está estruturado em sete áreas de conhecimento, 
conforme mostra a Figura 12.2. Cada uma das áreas de conhecimento será 
brevemente explorada nas seções seguintes. 
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Figura 12.2 - Relacionamento entre as áreas de conhecimento do BABOK® 

Adaptado de DBA (2009) 

Cada área de conhecimento é descrita em termos das tarefas necessárias 
para atingir os seus objetivos. Por sua vez, cada tarefa possui entradas, elemen¬ 
tos (ou conceitos-chave), técnicas, partes interessadas e saídas. 


12.2.3.1 Planejamento e Monitoramento da Análise de Negócios 

Esta área de conhecimento define as tarefas relacionadas ao planejamento 
e ao monitoramento das atividades de análise de negócios: 

□ Planejar a abordagem da análise de negócios (2,1) : seleçáo da abor¬ 
dagem mais adequada para uma organização realizar a análise de ne¬ 
gócios, podendo envolver escolha do ciclo de vida (cascata, métodos 
ágeis etc.), da metodologia de melhoria de processos, das ferramentas 
de análise e gerenciamento de requisitos, etc. 

□ Conduzir análise das partes interessadas (2,2): identificação das par¬ 
tes interessadas afetadas por uma iniciativa, determinando a sua in¬ 
fluência ou autoridade para aprovação dos produtos. 
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□ Planejar as atividades de análise de negócios (2,3) : identificação do 
escopo e dos produtos das atividades, de quais atividades serão reali¬ 
zadas, do cronograma e da estimativa de esforço. 

□ Planejar a comunicação da análise de negócios (2,4) : criação de um 
plano de comunicação para descrever a estrutura e o cronograma das 
comunicações relacionadas às atividades de análise de negócio (reu¬ 
niões de trabalho, reportes, validações etc.). 

□ Planejar o processo de gerenciamento de requisitos (2,5) : defini¬ 
ção do processo responsável por aprovar os requisitos para imple¬ 
mentação e por gerenciar as mudanças na solução ou no escopo de 
requisitos. 

□ Gerenciar o desempenho da análise de negócios (2.6) : garantia de 
que as atividades de análise de negócio estejam sendo executadas com 
a máxima eficácia possível. 


12.2.3.2 Elicitação 

Elicitar significa definir os requisitos de forma a garantir que sejam com¬ 
pletos, claros, corretos e consistentes. Isso pode incluir esclarecer questões 
latentes ou subjacentes, assim como explicitar informações ou respostas 
necessárias. 

Esta área de conhecimento define as tarefas relacionadas à elicitação dos 
requisitos do negócio, das partes interessadas, da solução e da transição: 

□ Preparar a elicitação (3.1) : garantia de que todos os recursos ne¬ 
cessários estão organizados e agendados para as atividades de 
elicitação. 

□ Conduzir a atividade de elicitação (3.2) : reunião com a(s) parte(s) 
interessada(s) para elicitar as informações referentes às suas necessi¬ 
dades reais. 

□ Documentar os resultados da elicitação (3.3) : registro das informa¬ 
ções fornecidas pela(s) parte(s) interessada(s) durante a elicitação. 

□ Confirmar resultados da elicitação (3.4) : validação dos requisitos de¬ 
clarados em relação à compreensão do problema e às necessidades 
da(s) parte(s) interessada(s). 
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12.2.3.3 Gerenciamento e Comunicação dos Requisitos 

Esta área de conhecimento define as tarefas que garantem que todas as par¬ 
tes interessadas tenham um entendimento comum da solução e que aquelas 
que tenham alçada para aprovação estejam de acordo com os requisitos a que 
a solução deve atender: 

□ Gerenciar o escopo e os requisitos da solução (4,1) : obtenção e ma¬ 
nutenção de consenso entre as partes interessadas, quanto ao escopo 
da solução e aos requisitos a serem implementados. 

□ Gerenciar a rastreabilidade dos requisitos (4,2) : criação e manutenção 
de relacionamentos entre objetivos de negócio, requisitos, artefatos 
gerados pela equipe e componentes da solução, para apoiar atividades 
como as de análise de negócio. 

□ Manter requisitos para reutilização (4,3) : gestão do conhecimento 
acerca dos requisitos, para que eles possam ser reutilizados por outras 
equipes após a sua implementação. 

□ Preparar o pacote de requisitos (4.4) : estruturação de conjuntos de 
requisitos previamente selecionados, de forma a facilitar o seu enten¬ 
dimento, sua comunicação e sua utilização por um (ou mais) grupo(s) 
de partes interessadas. 

□ Comunicar requisitos (4,5) : definição e utilização de mecanismos 
para apresentar os requisitos às partes interessadas, buscando uma 
compreensão comum. 


12.2.3.4 Análise Corporativa 

Esta área de conhecimento define as tarefas relacionadas à identificação de 
uma necessidade, um problema ou uma oportunidade de negócio, à definição 
da natureza de uma solução para atender a essa necessidade e à justificativa do 
investimento necessário para entregar essa solução: 

□ Definir a necessidade do negócio (5.1) : definição dos motivos pelos 
quais é necessário realizar uma mudança nas capacidades ou nos sis¬ 
temas organizacionais. 
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□ Avaliar gaps de capacidade (5.2) : identificação das novas capacidades 
(ainda não existentes) requeridas pela empresa para atender à neces¬ 
sidade do negócio. 

□ Determinar a abordagem da solução (5.3) : definição da aborda¬ 
gem mais viável para atender à necessidade do negócio, com de¬ 
talhes suficientes para definir o escopo da solução e preparar o 
business case. 

□ Definir o escopo da solução (5.4) : definir as novas capacidades que 
serão entregues pelo projeto. 

□ Definir o business case (5.5) : justificativa do investimento necessário 
para entregar uma solução proposta. 


12.2.3.5 Análise dos Requisitos 

Esta área de conhecimento define as tarefas relacionadas à análise dos re¬ 
quisitos declarados, visando definir quais capacidades uma solução potencial 
deve possuir para atender às necessidades das partes interessadas: 

□ Priorizar requisitos (6.1) : garantia de que os requisitos mais críticos 
sejam o foco das atividades de análise e implementação. 

□ Organizar requisitos (6.2) : estruturação dos requisitos em visões que 
permitam que a nova solução para o negócio seja abrangente, com¬ 
pleta, consistente e compreendida pelas partes interessadas. 

□ Especificar e modelar requisitos (6.3) : utilização de ferramentas 
como declarações de texto, matrizes, diagramas e modelos formais, 
para representar os desejos das partes interessadas e/ou o estado atual 
da organização. 

□ Definir suposições e restrições (6.4) : identificação de fatores que po¬ 
dem afetar a viabilidade das soluções. Suposições (ou premissas) são 
fatores supostamente verdadeiros, mas ainda não confirmados. Res¬ 
trições são limitações às soluções possíveis. 

□ Verificar requisitos (6.5) : avaliação das especificações e modelos de re¬ 
quisitos, em relação ao padrão mínimo de qualidade necessário para 
que sejam usados nas etapas seguintes do trabalho. 

□ Validar requisitos (6.6) : avaliação dos requisitos quanto ao valor 
entregue ao negócio, ao cumprimento das suas metas e das ne- 
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cessidades das partes interessadas, podendo acontecer durante ou 
após o projeto. 


12.2.3.6 Avaliação e Validação da Solução 

Esta área de conhecimento define as tarefas que visam garantir que as so¬ 
luções encontradas atendam às necessidades do negócio e facilitar que a sua 
implementação seja bem-sucedida: 

□ Avaliar a solução proposta (7.1) : avaliação das soluções propostas 
quanto ao atendimento dos requisitos das partes interessadas e da 
solução. 

□ Alocar requisitos (7.2) : distribuição dos requisitos das partes interes¬ 
sadas e da solução pelos vários componentes da solução e também 
pelo cronograma de liberações, visando maximizar o valor a ser en¬ 
tregue ao negócio. 

□ Avaliar a prontidão organizacional (73) : avaliação do quanto a or¬ 
ganização está preparada para a mudança organizacional que a nova 
solução trará, depois de implementada. 

□ Definir requisitos de transição (7.4) : definição de requisitos (tempo¬ 
rários) para criar capacidades novas, necessárias à transição da solução 
atual para a solução futura. 

□ Validar a solução (7.5) : garantia de que a solução atenda à neces¬ 
sidade do negócio e que os defeitos identificados sejam corrigidos 
apropriadamente. 

□ Avaliar o desempenho da solução (7.6) : avaliação do valor efetiva¬ 
mente entregue pelas soluções em produção, visando identificar 
oportunidades de melhoria. 


12.2.3.7 Competências Fundamentais 

Esta área de conhecimento descreve características, conhecimento, habi¬ 
lidades, atitudes e qualidades pessoais necessárias para a prática da Análi¬ 
se de Negócios. Tais competências são agrupadas no BABOK® da seguinte 


maneira: 
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□ Pensamento analítico e capacidade de resolução de problemas : com¬ 
preende qualidades como pensamento criativo, tomada de decisões, 
aprendizado, resolução de problemas e pensamento sistêmico. 

□ Características comportamentais : compreende qualidades como éti¬ 
ca, organização pessoal e confiabilidade. 

□ Conhecimento do negócio : compreende qualidades como entendi¬ 
mento dos princípios e práticas do negócio, conhecimento do merca¬ 
do, da organização e das soluções existentes. 

□ Habilidades de comunicação : compreende qualidades como didática 
e comunicação oral e escrita. 

□ Habilidades de interação : compreende qualidades como facilitação 
e negociação, liderança e influência e habilidade de trabalho em 
equipe. 

□ Aplicações de software : compreende habilidades de utilização de apli¬ 
cações genéricas (automação de escritório, por exemplo) e de apli¬ 
cações especializadas (para modelagem, validação e implementação). 


12.2.3.8 Técnicas Referenciadas 

O guia para o BABOK® faz referência a um conjunto de técnicas comu- 
mente utilizadas pelos Analistas de Negócios, aplicáveis a uma ou mais tarefas 
dentro das áreas de conhecimento. Algumas dessas técnicas são bastante co¬ 
nhecidas dos analistas de sistemas, pois fazem parte de abordagens metodoló¬ 
gicas de desenvolvimento de software. Entre tais técnicas, figuram: 

□ Definição de critérios de aceite e avaliação. 

□ Benchmarking. 

□ Brainstorming. 

□ Análise de regras de negócio. 

□ Dicionário de dados e glossário. 

□ Diagrama de fluxo de dados (DFD). 

□ Decomposição funcional. 

□ Modelagem de dados/classes. 

□ Análise de decisão. 

□ Análise de documentos. 

□ Estimativa. 
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□ Grupos focais. 

□ Análise de interface. 

□ Entrevistas. 

□ Lições aprendidas. 

□ Métricas e indicadores de desempenho. 

□ Análise de requisitos náo funcionais. 

□ Observação. 

□ Modelagem organizacional. 

□ Rastreamento de problemas. 

□ Modelagem de processos (BPM). 

□ Prototipagem. 

□ Workshop de requisitos. 

□ Análise de riscos. 

□ Análise de causa-raiz. 

□ Cenários e casos de uso (UML). 

□ Modelagem do escopo. 

□ Diagramas de sequência (UML). 

□ Diagramas de estados (UML). 

□ Revisáo estruturada. 

□ Pesquisa/questionário. 

□ Análise SWOT. 

□ Histórias de usuários. 

□ Avaliação de fornecedores. 

12 . 2.4 Aplicabilidade do modelo 

Há muito tempo temos ouvido do mercado que, nos projetos de TI, gran¬ 
de parte da atençáo tem sido dedicada ao planejamento e ao desenho dos 
sistemas, sobrando pouco para a definição dos produtos que serão entregues. 
Segundo Jonasson (2008), que também compartilha dessa impressão, o papel 
do Analista de Negócios tem evoluído e recebido cada vez maior importância 
no contexto dos projetos de TI das organizações (embora ainda não haja um 
padrão universalmente aceito para ele). 

O BABOK® cobre a atuação do Analista de Negócio durante todo o ciclo 
de gerenciamento de requisitos dentro de um projeto, ou seja, desde a fase 
de pré-projeto até a avaliação de eficácia após o seu encerramento, além de 
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abordar com maior profundidade assuntos como metodologias de desenvol¬ 
vimento de sistemas, técnicas de modelagem, garantia da qualidade e o en¬ 
volvimento dos vários níveis da organização nos projetos. Nesse sentido, pode 
ser aplicado a qualquer natureza de projeto, embora muito do seu foco esteja 
direcionado a projetos de desenvolvimento de software. 

Em relação a outros modelos de referência, o BABOK® possui grande afi¬ 
nidade, em particular, com o PMBOK® e o CMMI: 

□ O BABOK® pode ser utilizado como fundamentação dos princípios 
e práticas de Análise de Negócios, notadamente quando a principal 
preocupação da organização é o treinamento no levantamento de 
requisitos. 

□ O CMMI-DEV, com suas áreas de processos “Gestão de Requisitos” 
(Nível 2) e “Desenvolvimento de Requisitos” (Nível 3), pode ser uma 
boa opção se o principal objetivo da organização é implementar pro¬ 
cessos robustos de desenvolvimento de sistemas, desde que haja um 
forte comprometimento organizacional. 

□ O PMBOK®, por sua vez, com os processos da disciplina de Ge¬ 
renciamento do Escopo, pode ser mais adequado quando o foco for 
encerrar o trabalho, planejar os recursos, elaborar programações e 
orçamentos. 

De acordo com Jonasson (2008), não é recomendável que uma organi¬ 
zação altere com muita frequência o seu modelo de referência (por exem¬ 
plo, do CMMI-DEV para o PMBOK e deste para o BABOK®), e sim que 
seja escolhido um modelo como padrão de fundamentos e sejam adiciona¬ 
das gradativamente algumas das características e boas práticas dos demais 
modelos. 


12 . 2.5 Benefícios do modelo 

O BABOK® traz para a profissão de Analista de Negócio um rico con¬ 
junto de “melhores práticas” compiladas e detalhadas nas suas áreas de co¬ 
nhecimento, propiciando um maior grau de padronização na forma como 
os produtos dos projetos são concebidos e seus requisitos são especificados, 
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alocados aos componentes do produto e avaliados quanto ao seu atingimen- 
to ou náo. 

Nesse sentido, a adoção de suas práticas pelos profissionais de Análise de 
Negócio de uma organização pode trazer benefícios como: 

□ Redução das barreiras de comunicação entre a TI e as áreas do negó¬ 
cio. Um Analista de Negócio pode atuar como interlocutor entre as 
partes envolvidas, entendendo os objetivos da organização, os requi¬ 
sitos, as premissas e restrições existentes, e procurando obter um con¬ 
senso entre todas as partes interessadas envolvidas quanto à melhor 
solução a ser implementada. 

□ Maior eficácia no levantamento de requisitos, assim como na sua 
classificação, priorização e gerenciamento ao longo de todo o ciclo de 
vida do produto. 

□ Maiores subsídios para mensurar o quanto a Análise de Negócio in¬ 
fluencia as capacitações da TI para atender ao seu cliente. 

□ Serve como base fundamental de conhecimentos para todo profis¬ 
sional de Análise de Negócio, ou seja, seu conteúdo é básico para 
qualquer avaliação ou certificação neste mercado. 

□ Apresenta um glossário que visa padronizar a terminologia relativa à 
Análise de Negócio utilizada em todo o mundo, o que se constitui 
em um grande estímulo à universalização dos conhecimentos dessa 
disciplina. 


12 . 2.6 Certificações relacionadas 

O IIBA possui um programa de certificação destinado a profissionais que 
atuam na área de análise de negócios (no mínimo quatro anos ou 5.000 horas 
de experiência profissional comprovada em trabalhos relacionados a BPM), o 
CBAP® {Certified Business Analysis Professional). 

Os requisitos para certificação no CBAP® são 7.500 horas (ou cinco 
anos) de trabalho em atividades de análise de negócio nos últimos dez 
anos, experiência e conhecimento em quatro áreas de conhecimento do 
BABOK®, participação em cursos relacionados à análise de negócios e duas 
cartas de recomendação de chefes, clientes ou de profissionais já certifica¬ 
dos no CBAP®. 
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A certificação tem validade por três anos e a recertificação requer que o 
candidato se comprometa com um programa de educação continuada, cum¬ 
prindo uma quantidade mínima de horas em cada período. 

Mais recentemente, foi criada também a certificação CCBA® ( Certificate of 
Competency in Business Analysis) , cujos requisitos são similares aos do CBAP®, 
porém com exigência de metade das horas de trabalho em análise de negócio 
(3.750 horas), o que permite um degrau intermediário de certificação. 

Maiores detalhes sobre as certificações CBAP® e CCBA® podem ser obtidos 
no site do capítulo brasileiro do IIBA (www.theiiba.org.br). 


12.3 Balanced Scorecard 
12 . 3.1 Histórico do modelo 

O Balanced Scorecard surgiu através de uma pequisa do Nolan Norton Insti- 
tute, então um braço de pesquisa da KPMG Consulting (atual Bearing Poini), 
sobre a medição de desempenho na organização do futuro. 

De acordo com Kaplan & Norton (1996), o estudo foi motivado pela 
crença de que a medição de desempenho somente considerando indicadores 
financeiros estava obsoleta e que basear-se somente nessas medidas de desem¬ 
penho inabilitava as empresas a criar valores econômicos futuros. 

David Norton foi o líder do estudo, enquanto Robert Kaplan foi um con¬ 
sultor acadêmico. Juntamente com o Nolan Norton Institute, representantes 
de várias empresas 115 participaram do estudo para propor um novo modelo de 
medição de desempenho. O estudo transcorreu durante o ano de 1990. 

O estudo examinou vários casos de sistemas inovadores de medição de 
desempenho. Um dos casos que chamou atenção do grupo foi o da Analog 
Devices , que criou um scorecard corporativo contendo, além das medições fi¬ 
nanceiras, medições sobre entregas aos clientes, qualidade e ciclo de tempo na 
manufatura e eficácia do desenvolvimento de novos produtos. 

A partir dos estudos de caso, os participantes do grupo do estudo co¬ 
meçaram a focalizar sua atenção para um scorecard multidimensional. Isto 


115 Entre as empresas participantes do estudo figuravam: Advanced Micro Devices, American Standard, 
Apple Computer, Bell South, CIGNA, Conner Peripherals, Cray Research, DuPont, EDS, GE, HPe Shell 
Canadá. 
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resultou no que chamaram de Balanced Scorecard (BSC), organizado por 
quatro perspectivas: financeira, clientes, processos internos e aprendizado e 
crescimento. 

Esse nome foi dado por refletir o balanço entre objetivos de curto e longo 
prazos, medidas financeiras e náo financeiras, indicadores de resultados e de 
desempenho e entre perspectivas internas e externas de desempenho. 

O primeiro resultado publicado do estudo, de forma extensiva, foi divul¬ 
gado através de um artigo na Harvard Business Revieiv (edição de janeiro- 
-fevereiro de 1992), intitulado The Balanced Scorecard — Measures that drive 
performance. 

Posteriormente, a aplicação do Balanced Scorecard foi sendo aprimorada. 
Através de um trabalho com a Rockwater e a FMC Corporation , a aplicação do 
BSC foi ampliada como um instrumento de alinhamento e desdobramento 
da estratégia da empresa. Isso significou que o BSC poderia passar de uma 
sistemática de medição de indicadores de desempenho para um sistema de 
gestão estratégica de uma empresa, e que também poderia ser aplicado como 
um instrumento de comunicação da estratégia. 

Entre 2001 e 2004, Kaplan e Norton, em suas pesquisas periódicas com 
empresas, descobriram que os executivos estavam ligando, numa relação de 
causa e efeito, os indicadores das perspectivas aprendizado e crescimento, pro¬ 
cessos internos, clientes e financeira, o que chamaram de “Mapas Estratégi¬ 
cos”. O Mapa Estratégico permite a visualização da estratégia da empresa de 
uma forma que os executivos entendem, além de também permitir o alinha¬ 
mento e a comunicação efetiva da estratégia e de seus desdobramentos por 
toda a empresa. 


12 . 3.2 Objetivos do modelo 

O Balanced Scorecard é um sistema de gestão estratégica que tem por 
objetivos: 

□ Traduzir a estratégia da empresa em termos operacionais. 

□ Alinhar a organização à estratégia. 

□ Transformar a estratégia em tarefas de todos. 

□ Converter a estratégia em processo contínuo. 

□ Mobilizar a mudança por meio da liderança executiva. 
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12 . 3.3 Estrutura do modelo 

12.3.3.1 O Balanced Scorecard 

Esta abordagem de gestão estratégica foi desenvolvida porque até então 
todas as medidas de desempenho das empresas eram financeiras. De acordo 
com Kaplan & Norton (1996), o resultado financeiro é resultado de outros 
fatores ou perspectivas: 

□ Clientes. 

□ Processos internos. 

□ Aprendizado e crescimento. 

O BSC é fundamentado nessas quatro perspectivas e determina uma re¬ 
lação de causa e efeito, como mostra a Figura 12.3, assim como relaciona 
objetivos com medições, metas e iniciativas, que são os projetos e serviços que 
devem ser implantados para o atendimento aos objetivos e às metas. 
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Figura 12.3 - Modelo do BSC de Kaplan & Norton (1996) 
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O BSC é um instrumento que auxilia o alinhamento de todas as ini¬ 
ciativas de todos os níveis da empresa com os objetivos e as estratégias do 
negócio. 

As etapas para construir um BSC sáo: 

□ Estabelecer a visão da empresa sobre o futuro que ela deseja atingir. 

□ Perspectivas: a visão é decomposta nas perspectivas financeira, de 
cliente, de processos internos e de aprendizado e crescimento ou ou¬ 
tras, a critério da empresa. 

□ Objetivos estratégicos: a visão é expressa em objetivos estratégicos 
que, uma vez atingidos, permitem à empresa chegar ao futuro dese¬ 
jado (são estabelecidos objetivos estratégicos para cada perspectiva 
estabelecida). 

□ Determinação das medições estratégicas: definir tanto os indicadores 
de resultado (lagging indicators ) como os indicadores de desempenho 
(performance indicators ) para cada objetivo estratégico, considerando 
cada uma das perspectivas. 

□ Determinar relações de causa e efeito, descrevendo como os objetivos 
se relacionam entre si. 

□ Estabelecer o scorecard. representação dos objetivos por perspectiva e 
pelas relações de causa e efeito. 

□ Desdobrar o scorecard , relacionando-o às unidades organizacionais da 
empresa, até o nível mais baixo. 

□ Determinar metas quantitativas para cada um dos indicadores de re¬ 
sultado e de desempenho. 

□ Determinar as iniciativas: projetos, ações e serviços que possibilitarão 
a realização dos objetivos estratégicos (na realidade, são planos de 
ação). 

□ Implantar o BSC: comunicar e disseminar por toda a organização. 

□ Manter o esforço: manter e evoluir continuamente o sistema de ges¬ 
tão estratégico. 

A perspectiva financeira descreve os resultados esperados da estratégia em 
termos financeiros tradicionais. 

A perspectiva do cliente descreve a proposição de valor para o cliente. 

A perspectiva dos processos internos identifica os processos críticos para a 
geração de valor para o cliente. 
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A perspectiva de aprendizado e crescimento identifica os ativos intangíveis 
que sáo críticos para os processos internos e para a geração de valor para o 
cliente. 


12.3.3.2 Os mapas estratégicos 

O Mapa Estratégico é uma representação visual das relações de causa e 
efeito entre os objetivos estratégicos, nas quatro perspectivas estratégicas com¬ 
preendidas pelo BSC. 

De acordo com Kaplan & Norton (2004), o Mapa Estratégico representa 
como a empresa cria valor. É considerado o “elo perdido” entre a formulação 
da estratégia e a sua execução. 

A Figura 12.4 apresenta um mapa estratégico genérico. 
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Figura 12.4 - Mapa estratégico genérico 
Adaptado de Kaplan & Norton (2004) 
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O Mapa Estratégico dirige o BSC e, por consequência, as iniciativas e os 
investimentos necessários. 


12 . 3.4 Aplicabilidade do modelo 

O Mapa Estratégico e o Balanced Scorecard constituem-se numa poderosa 
ferramenta para realizar o alinhamento da TI ao negócio e para desdobrar os 
objetivos estratégicos de TI em iniciativas que contribuam para o atendimen¬ 
to aos objetivos. 

As iniciativas ou os projetos a serem implantados podem estar refletidos no 
Portfólio de TL 

As figuras 12.5 e 12.6 apresentam um modelo genérico de Balance d Score¬ 
card para TI. 

Em TI, o BSC deve ser usado durante o planejamento da tecnologia da 
informação, assim como na gestão do dia a dia da realização da estratégia 
de TI. 



Figura 12.5 - BSC para TI 
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Figura 12.6 - Exemplo de BSC para TI 


12 . 3.5 Benefícios do modelo 

A aplicação do BSC como sistema de gestão estratégica tem sido relativa¬ 
mente recente, principalmente no Brasil. 

De acordo com Coutinho & Kallás (2005), em pesquisa realizada com tre¬ 
zentas empresas pelo Balanced Scorecard Collaborative (BSCOL), os seguintes 
benefícios foram obtidos pelos participantes: 

□ Alinhamento da organização à estratégia. 

□ Busca de sinergia organizacional. 

□ Construção de um sistema de gestão da estratégia. 

□ Vinculação da estratégia com planejamento e orçamento. 

□ Definição de metas estratégicas. 

□ Priorização de iniciativas estratégicas. 

□ Alinhamento dos indivíduos da organização à estratégia. 

Conforme esses autores, há uma dificuldade intrínseca na medição 
dos benefícios quantitativos na adoção do BSC, pois o resultado de uma 
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empresa está condicionado a muitas variáveis que náo estáo sob o seu 
controle. 

Há, ainda, o aspecto de que, se a empresa náo optou pelas estratégias cor¬ 
retas, é muito provável que, a despeito do uso de modernas tecnologias de 
gestáo, seu desempenho náo seja satisfatório. 

Entretanto, simulando o desempenho de uma carteira de ações de empre¬ 
sas listadas na Bovespa e que já empregavam o BSC, considerado o período 
de 2003 a 2005, obtiveram-se índices de valorização das respectivas ações 
bem superiores ao índice Ibovespa para o mesmo período, demonstrando 
preliminarmente que o uso consistente do BSC pode levar a melhores de¬ 
sempenhos empresariais. 

Na área de TI, já existem aplicações do BSC, por força de sua adoçáo pela 
empresa como um todo, porém ainda há poucas informações sobre os resul¬ 
tados de sua aplicação. 

Nos estudos de caso que apresentamos neste livro, falaremos sobre a apli¬ 
cação do BSC em casos reais de empresas instaladas no Brasil. 


12.3.6 Certificações relacionadas 

No que concerne ao BSC, náo há certificações profissionais nem empre¬ 
sariais no Brasil. Nos Estados Unidos, existe um programa de certificação 
profissional estabelecido pelo The Balanced Scorecard Institute, considerado o 
organismo certificador original para os praticantes do BSC. Este programa, 
que é oferecido em conjunto com o George Washington University College of 
Professional Studies, inclui dois níveis de certificação: o Balanced Scorecard 
Master Professional™ (BSMP) e o Balanced Scorecard Professional ' 
(BSP). Para maiores detalhes, vide página http://www.balancedscorecard. 
org/certification. 

Entretanto, soluções de software podem ser certificadas pelo Balanced 
Scorecard Collaborative, que é uma instituição criada pelos professores Kaplan 
e Norton, os “pais” do BSC. 

Da mesma forma, empresas podem ser associadas ao Balanced Scorecard 
Collaborative e firmar parcerias para serviços de implantação do BSC. 
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12.4 Seis Sigma 
12 . 4.1 Histórico do modelo 

As raízes do Seis Sigma como um padrão de medição vêm dos trabalhos 
realizados por Cari Frederick Gauss (1777-1855), que introduziu o conceito 
da curva normal ou curva de Gauss. Como medida de controle da variação de 
processos, vêm dos trabalhos de Walter Shewhart, na década de 1930, o qual 
demonstrou que a partir de três desvios padrões ou três “sigmas” da média, o 
processo necessita de correção. Esses trabalhos deram base para o movimento 
da qualidade total, liderado mais tarde por Edward Deming e outros profis¬ 
sionais e militantes da qualidade. 

O termo Seis Sigma foi cunhado pelo engenheiro da Divisão de Comu¬ 
nicações da Motorola, Bill Smith, em 1986. Esse conceito foi desenvolvido a 
partir de informações vindas da força de vendas, a respeito da grande quanti¬ 
dade de reclamações de uso de garantias pelos clientes. 

Em 1987, foi lançado um ambicioso programa por Bob Galvin, então 
CEO da Motorola, visando a redução de defeitos nos produtos para “seis 
sigma” ou 3,4 defeitos por milhão de oportunidades, tendo como meta o ano 
de 1991 e como pilar o modelo Seis Sigma. 

Em 1988, a partir dos esforços de melhoria da qualidade dos processos, a Mo¬ 
torola ganhou o prestigioso prêmio Malcolm Baldrige National Quality Award 
(MBNQA), que vem a ser o prêmio nacional da qualidade norte-americano. 

Em 1991, a Motorola introduziu treinamentos para a formação de especia¬ 
listas em Seis Sigma, que foram denominados black belts. Em 1992, a meto¬ 
dologia passou a ser adotada por outras indústrias, incluindo seguros, serviços 
financeiros, saúde etc. 

Em 1999, a Motorola, através da Motorola University, começou a ensinar 
o Seis Sigma para outras organizações de sua cadeia de valor (fornecedores e 
clientes) e também para outras indústrias. 

Em 2002, a Motorola ganhou novamente o MBNQA e o Seis Sigma se 
tornou, de fato, uma metodologia orientada para obtenção de resultados para 
o negócio. Em outras palavras, seu foco se alargou para além da melhoria da 
qualidade em produtos. 

Em 2004, a Motorola obteve receitas 42% maiores e um lucro por ação 
257% maior do que no primeiro trimestre do ano fiscal anterior com o uso 
do Seis Sigma em todos os seus processos. 
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12 . 4.2 Objetivos do modelo 

De acordo com Pande, Neuman & Cavanagh (2001), Seis Sigma é: “um 
sistema abrangente e flexível para alcançar, sustentar e maximizar o sucesso em¬ 
presarial. É singularmente impulsionado por uma estreita compreensão das ne¬ 
cessidades dos clientes, pelo uso disciplinado de fatos, dados e análise estatística e 
pela atenção diligente à gestão, melhoria e reinvenção dos processos de negócio”. 

O objetivo principal do Seis Sigma é a melhoria do desempenho do negó¬ 
cio através da melhoria do desempenho de processos, tendo como meta um 
processo que apresente 3,4 defeitos sobre um milhão de oportunidades, ou 
o “sigma 6”, que equivale a um rendimento de 99,9997% de resultados do 
processo isentos de defeitos. 

Os objetivos do Seis Sigma variam de acordo com os objetivos da melho¬ 
ria, conforme a lista a seguir: 

□ Redução de custos. 

□ Melhoria da produtividade. 

□ Crescimento de fatia de mercado. 

□ Retenção de clientes. 

□ Redução de tempo de ciclo. 

□ Redução de defeitos. 

□ Mudança cultural para a qualidade. 

□ Excelência no desenvolvimento de produtos e serviços. 

Ao contrário do Total Quality Management (TQM), que pretendia melhorar 
a qualidade de toda a organização, o Seis Sigma procura melhorias que agreguem 
valor para o cliente e também pode ser aplicado para problemas localizados. 

Entretanto, é bom deixar claro que o Seis Sigma emprega as mesmas técni¬ 
cas preconizadas pelo TQM 116 . A Tabela 12.3 a seguir mostra o que significa o 
Seis Sigma em termos de qualidade e defeitos por milhão. 


Sigma 

Qualidade 

Defeitos por milhão 

6a 

99,9997% 

3,4 

5a 

99,9767% 

233 

4a 

99,379% 

6210 


116 Vide em Shiba et al (1993) uma abordagem holística do TQM. 
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Sigma 

Qualidade 

Defeitos por milhão 

3a 

93,32% 

66807 

2 a 

69,1% 

308537 

la 

31% 

690000 


Tabela 12.3 - Qualidade e defeitos sigma 


12 . 4.3 Estrutura do modelo 

12.4.3.1 A metodologia DMAIC 

A implantação do Seis Sigma tem como alicerce a metodologia DMAIC, 
que significa Define, Measure, Analyze, Improve and Control e que evidencia as 
etapas de sua aplicação 117 . 

A Figura 12.7 mostra o modelo com suas atividades principais. 



Identificar processos essenciais e clientes-chave 

• Identificar processos centrais de negócio 

• Definir saídas de processos e clientes-chave 

• Criar mapas de processos centrais de alto nível 


Definir necessidades dos clientes 

• Coletar dados sobre o cliente - desenvolver estratégia "voz do 
cliente" 

• Desenvolver padrões de desempenho e declarações dos requisitos 

• Analisar e priorizar necessidades - avaliar estratégia do negócio 


Medir o desempenho atual 


Planejar e executar medições de desempenho dos requisitos do 
cliente 

Obter medidas de base de defeitos e identificar oportunidades de 
melhoria 


| Priorizar, analisar e implantar melhorias 

• Selecionar projetos de melhoria 

• Analisar, desenvolver e implantar soluções focadas nas causas- 
raízes 

• Projetar ou reprojetar processos de trabalho novos e eficazes 


Expandir e integrar o sistema Seis Sigma 

Implantar medidas e mandamento e ações para manter a 
melhoria 

Definir responsabilidades para a propriedade e o gerenciamento 
do processo 

Manter o sistema Seis Sigma 


Figura 12.7 - Metodologia Seis Sigma 
Adaptado de Pande, Neuman & Cavanagh (2001) 


117 Conforme Tonini (2005), existem metodologias alternativas, porém variantes da DMAIC. 
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A etapa Identificar processos essenciais e clientes-chave tem por objetivos 
a obtenção do conhecimento sobre os processos de negócio mais críticos para 
a empresa e o entendimento sobre como esses processos interagem com os 
clientes. Como resultado, obtém-se o entendimento sobre quais processos 
agregam valor para os clientes, quais produtos e serviços são, de fato, en¬ 
tregues para os clientes e como os processos fluem na empresa entre os seus 
departamentos e divisões. 

A etapa Definir as necessidades dos clientes tem por objetivo o estabe¬ 
lecimento de padrões de desempenho a partir da “voz do cliente”, ou seja, 
com base em informações sobre os requisitos dos clientes para os produtos 
e serviços, de forma que o atendimento a tais requisitos possa ser medido e 
que sejam desenvolvidas formas de captar o que o cliente realmente requer. 
Como resultado desta etapa, obtém-se uma lista de requisitos dos clientes dos 
produtos e dos serviços associados. 

Deve-se observar que isso é uma grande mudança de paradigma para mui¬ 
tas empresas que desenvolvem os produtos e serviços a partir da percepção 
interna do que realmente os clientes necessitam. 

A etapa Medir o desempenho atual tem por objetivos avaliar o desem¬ 
penho dos processos que geram produtos e serviços para os clientes e es¬ 
tabelecer um processo de medição e análise para realizar as medições dos 
processos. Como resultado, obtêm-se as medições dos processos, medições 
de capacidade dos processos, e é estabelecido um sistema de medição. Esses 
resultados auxiliarão a empresa a descobrir mais sobre os pontos em que 
necessita melhorar. 

A etapa Priorizar, analisar e implantar melhorias tem por objetivos a 
identificação das oportunidades de melhoria que agregarão valor para o 
cliente, o desenvolvimento de soluções para os processos e a implanta¬ 
ção das melhorias de alto impacto. Como resultado, obtêm-se as priorida¬ 
des definidas, as soluções de melhoria, os novos processos ou os processos 
ajustados. 

A etapa Expandir e integrar o sistema Seis Sigma significa expandir o Seis 
Sigma para os demais processos, manter indefinidamente o esforço Seis Sigma 
e monitorar os processos, com fatos e dados, visando a sua melhoria contínua, 
sempre com foco na satisfação do cliente. Cabe lembrar que as necessidades 
dos clientes são variáveis e vão crescendo com o tempo; portanto, os processos 
da empresa devem sempre ser revistos. Os resultados desta etapa são: a insti- 
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tucionalização do controle dos processos, a identificação dos “donos” dos pro¬ 
cessos, planos de resposta (caso haja uma variação nas estratégias do negócio 
e nas necessidades dos clientes) e, por fim, a cultura Seis Sigma impregnada 
na empresa. 


12.4.3.2 As ferramentas usadas pelo Seis Sigma 

A Tabela 12.4, a seguir, lista as ferramentas e técnicas usadas pelo Seis Sig¬ 
ma. Apesar de não ser uma lista definitiva, está bastante abrangente. 

E importante ressaltar que o conjunto de técnicas a serem usadas em um 
programa Seis Sigma depende da natureza do problema que está sendo estu¬ 
dado, do tempo necessário para se fazerem as descobertas e de outros tipos de 
restrições, como, por exemplo, a falta dos dados necessários para o trabalho. 
Ou seja, embora o leitor possa se assustar com a profusão de técnicas para Seis 
Sigma, em geral não precisará usar todas, mas apenas parte delas. 


Técnica 

Descrição 

SIPOC - Supplier, Input, Process, Output, 
Customer 

É uma técnica de diagrama que tem por objetivo o “desenho” de 
processos de negócio. 

Diagrama de Pareto 

Técnica básica de qualidade que permite verificar a frequência 
das causas de variação de um processo. 

Diagrama de espinha de peixe (ou 

Diagrama de Ishikawa) 

Permite entender as causas-raízes especiais e comuns de 
variação para os processos. 

QFD - Quatity Function Deployment 

Permite a especificação dos requisitos do cliente, confrontando- 
os contra os atributos atuais do produto e serviço e contra a 
concorrência. 

Business intelligence e data mining 

São técnicas para a descoberta de dados sobre o 
comportamento dos clientes em relação aos produtos e 
serviços da empresa (para quem tem os dados das transações 
armazenados em data warehouses). 

Scorecards de clientes 

Credite behaviourscores mostram o perfil e o comportamento 
do cliente em relação à empresa. 

Pesquisas direcionadas 

Pesquisas de mercado direcionadas para os clientes da 
empresa. 

Goat Driven Measurement 

Técnicas como esta auxiliam a implantar um processo de 
medição e análise. 
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Técnica 

Descrição 

Estatística básica e descritiva 

Média, desvio padrão, moda, mediana, dispersão, distribuição de 
probabilidades etc. 

Amostragem 

Permite a seleção de uma amostra que represente o universo 
dos itens ou indivíduos em análise. 

Testes de hipóteses 

Técnica usada para testar hipóteses sobre causas de variação 
de processos e sobre soluções. 

Reprodutibilidade x Repetitividade ou R&R 

Técnica muito usada em metrologia, que serve para verificar 
variações de resultados de medição, em função da variação de 
pessoas e de equipamentos de medição. 

Análise de variância ou ANOVA 

Utilizado para análise e comparação entre grupos de amostras, 
conforme uma variável (tempo, velocidade, defeito etc.). 

Histograma ou Tabela de frequência 

Mostra graficamente a variação de um grupo de dados. 

Gráfico de dispersão 

Mostra a dispersão entre variáveis que estão em análise. 

Brainstorming 

Técnica para processos de criação e identificação de causas e 
soluções. 

Análise de valor 

Técnica usada para analisar quais atividades agregam valor ao 
processo de negócio. 

Balanced scorecard 

Usado para mostrar os objetivos de desempenho do produto ou 
serviço e o seu desdobramento em objetivos de menor nível. 

Process scorecard 

Mostra o desempenho do processo durante a implantação das 
melhorias provocada pelo Seis Sigma e durante a manutenção 
do esforço. 

CEP - Controle Estatístico de Processo 

Serve para monitorar o desempenho do processo conforme 
os atributos de medição e mostra se o processo está sendo 
desempenhado dentro dos limites (superior e inferior) 
especificados. 

Qui-quadrado 

Teste de variância entre amostras. 

Teste-t 

Teste de significância estatística entre grupos de amostra. 

Análise multivariada 

Usado para comparar, simultaneamente, vários atributos que se 
quer observar nas amostras. 

Regressão linear 

Analisa a linearidade entre variáveis dependentes e 
independentes, ou seja, uma variável é função de uma ou mais 
de uma. 

Projetos de experimentos (experimentos 
fatoriais) 

Planeja e controla variáveis usando uma experiência. Por 
exemplo, verifica a melhor combinação de variáveis para se 
obter o melhor resultado. 
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Técnica 

Descrição 

Análise de modo e efeitos de falha ou 

Failure Mode and Effect Analysis (FMEA) 

É uma técnica de prevenção que identifica defeitos potenciais 
em processos. 

Análise da árvore de falhas ou Fault Tree 
Analysis (FTA). 

É uma técnica usada para analisar defeitos que ocorreram e 
identificar as causas. 

Dispositivos à prova de falhas ( Poka-Yoke) 

Enfatizam a detecção e correção de defeitos antes que o produto 
ou serviço seja entregue para o cliente. Foca o erro humano. 


Tabela 12.4 - Técnicas usadas no Seis Sigma 


12.4.3.3 Requisitos para programas Seis Sigma 

Um programa Seis Sigma tem como requisitos: 

□ Alinhar o esforço Seis Sigma aos objetivos de negócio. 

□ Forte patrocínio da administração. 

□ Focalizar em resultados de curto prazo. 

□ Implantar como uma nova forma de administração duradoura. 

□ Tornar a aprendizagem uma tarefa contínua. 

□ Selecionar os projetos corretos. 

□ Ênfase em treinamento e capacitação de recursos humanos. 

□ Definir claramente papéis e responsabilidades. 

□ Forte liderança para a mudança. 


12.4.3.4 Papéis e responsabilidades no esforço do Seis Sigma 

De acordo com Pande, Neuman & Cavanagh (2001), a metodologia Seis 
Sigma requer, para a sua implantação, alguns papéis e responsabilidades: 

□ Grupo de liderança, responsável por estabelecer a infraestrutura da 
iniciativa, selecionar os projetos, rever o progresso dos projetos, pa¬ 
trocinar a mudança, compartilhar melhores práticas por toda a orga¬ 
nização, remover barreiras etc. 

□ Patrocinador ou campeão, gerente sênior que supervisiona um pro¬ 
jeto de melhoria, determina as metas para os projetos de melhoria, 
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provê coaching para as iniciativas, obtém recursos para os projetos, 
resolve conflitos, trabalha com os “proprietários dos processos”, re¬ 
presenta a equipe do projeto junto ao grupo de liderança, resolve 
sobreposições de projetos etc. 

□ O Líder da implantação envolve-se no dia a dia dos projetos e apoia 
o grupo de liderança na seleção e análise de projetos, identifica pes¬ 
soas para o projeto, incluindo consultoria e treinamento, prepara 
e executa planos de treinamento, auxilia os patrocinadores, docu¬ 
menta o progresso e os resultados e executa o endomarketing. Suas 
responsabilidades abrangem todas as iniciativas de Seis Sigma na 
empresa. 

□ O Coach oferece consultoria interna para o projeto, ajudando a es¬ 
timar o potencial de retorno do projeto e a validar os resultados, a 
coleta e a análise dos dados. 

□ O Líder da equipe assume a responsabilidade pelo resultado de um 
projeto. Em outras palavras, planeja, gerencia e controla um projeto, 
e comunica o seu progresso aos grupos interessados. 

□ Os Membros da equipe do projeto executam as atividades planejadas 
para o projeto. 

□ O “proprietário do processo” é a pessoa que vai assumir e gerenciar o 
processo na etapa de manutenção e expansão do Seis Sigma. 

Merecem destaque na definição de papéis e na capacitação das equipes 
as figuras dos “faixas pretas” ( black belts), dos “mestres faixas-pretas” ( master 
black belts ) e dos “faixas verdes” {green belts). 

O “faixa-preta” é um profissional com domínio da metodologia Seis Sigma 
e do uso das técnicas preconizadas e que já possui pelo menos dois projetos 
bem-sucedidos no currículo. Este profissional pode ser o coach ou líder da 
equipe. 

O “mestre faixa-preta” é um “faixa-preta” com vários projetos de sucesso 
conduzidos, com mais experiência do que o “faixa-preta”, e que pode ocupar 
o papel de líder da implantação ou de coach. 

Por fim, os “faixas-verdes” são membros da equipe do projeto que conhe¬ 
cem a metodologia Seis Sigma e sabem como coletar e analisar dados e são 
capazes de atuar como facilitadores para outras equipes de projetos e de geren¬ 
ciar projetos Seis Sigma do início ao fim. 
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De acordo com Pyzdek & Keller (2011), em programas Seis Sigma sóli¬ 
dos, como os de grandes indústrias, os black belts costumam representar cerca 
de 1% da força de trabalho, e existe um master black belt para cada black belt. 
Um black belt completa, em média, cinco a sete projetos Seis Sigma por ano, 
trabalhando com suas equipes. Em geral, há muito mais green belts do que os 
demais perfis, uma vez que não se dedicam integralmente ao programa Seis 
Sigma. 


12 . 4.4 Aplicabilidade do modelo 

O modelo pode ser aplicado para projetos de melhoria de processos, geren¬ 
ciamento do processo e para projetos de novos processos. 

Na área de TI, pode ser aplicado em processos de desenvolvimento de sof¬ 
tware, principalmente em fábricas de programas e manutenção de sistemas, 
onde há maior quantidade de projetos e um maior índice de repetição. 

Na área de segurança da informação, há um campo vasto para identificar 
melhorias nos processos de segurança, assim como nos processos de infraes- 
trutura, em especial gerenciamento de incidentes, gerenciamento de proble¬ 
mas, gerenciamento da disponibilidade e central de serviços. 

O Seis Sigma também pode ser utilizado em questões de apoio ao CIO, 
como no caso de elaboração de orçamento, controle de custos etc. 


12 . 4.5 Benefícios do modelo 

Na indústria de TI, ainda há poucos dados sobre a aplicação do Seis 
Sigma. 

Conforme dados da CIO Magazine (vide Mayor 2003), alguns benefícios 
publicados são: 

□ A organização de TI da Raytheon Aircraft teve um ganho de US$ 500 
mil em um único projeto. 

□ A TI da Textron teve um ganho de US$ 5 milhões em seis meses de 
aplicação do Seis Sigma. 

□ A Fidelity Wide Processing estava esperando um ganho de US$ 6 mi¬ 
lhões a US$ 8 milhões no ano de 2003 com o Seis Sigma. 
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Em termos empresariais, alguns resultados publicados (vide Kwak & An- 
bari 2004) sáo: 

□ Motorola reduziu os níveis de defeitos em processo em 150 vezes. 

□ Raytheon reduziu o tempo de inspeção de manutenção em 88% me¬ 
dido em dias. 

□ Allied Signal - fabricação de peças de automóveis - reduziu de dezoi¬ 
to para oito meses o ciclo de concepção - entrega. 

□ Hughes Aircraft aumentou a qualidade em 1000% e a produtividade 
em 500% na área de soldagem de mísseis. 

□ General Electric teve um ganho de US$ 2 bilhões em 1999. 

□ Motorola ganhou US$ 15 bilhões ao longo de onze anos. 

□ Texas Instruments obteve ganho de US$ 600 milhões. 

□ Honeywell obteve ganho de US$ 1,2 bilhão. 

□ Anderson Câncer Center da Universidade do Texas reduziu o tempo de 
preparação de pacientes para exames de laboratório de 45 para cinco 
minutos. 


12 . 4.6 Certificações relacionadas 

Existem certificações profissionais relativas a Master Black Belt , Black Belt e 
Green Belt , que são fornecidas pela Motorola University , por empresas especia¬ 
lizadas e pela American Society for Quality (ASQ). 

Esta última é uma organização não governamental dedicada a assuntos 
relacionados à qualidade, cujas certificações são mundialmente reconhecidas 
e cujos programas formam a base para várias outras entidades certificadoras, 
sendo considerada a mais qualificada para tal. 

Existe ainda a certificação Yellow Belt , destinada a formar especialistas na 
aplicação da metodologia e das ferramentas relacionadas para participar como 
membros das equipes de projetos Lean Seis Sigma, oferecida por diversas 
instituições. 

Não há certificação de organizações para o Seis Sigma, apenas certificação 
de profissionais. 
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12.5 TOGAF 

12 . 5.1 Histórico do modelo 

O TOGAF {The Open Group Arcbitecture Framework ) foi desenvolvido 
pelo The Open Group , que é uma organização não governamental, não vin¬ 
culada a fornecedores nem a consórcios de tecnologia, dedicada a promover 
a integração da informação dentro das empresas e entre elas com base em 
padrões abertos e na interoperabilidade global. 

O The Open Group trabalha com clientes (compradores), fornecedores, 
consórcios e outros organismos padronizadores. Seu papel é capturar, enten¬ 
der e tratar requisitos atuais e emergentes, estabelecer políticas e compartilhar 
melhores práticas para facilitar a interoperabilidade, desenvolver consenso e 
evoluir e integrar especificações de tecnologias open source e operar certifica¬ 
ções, incluindo a Certificação UNIX®. 

O desenvolvimento original da versão 1 do TOGAF ocorreu em 1995 e foi ba¬ 
seado no TechnicalArchitecture Framework for Information Management (TAFIM), 
desenvolvido pelo Departamento de Defesa dos Estados Unidos (DoD), que foi 
um investimento de milhões de dólares do governo norte-americano. 

Desde 1995 o The Open Group vem desenvolvendo sucessivas versões do 
TOGAF. Em 2011, foi disponibilizada aversão 9.1 do modelo. 


12 . 5.2 Objetivos do modelo 

O TOGAF é um framework de arquitetura que fornece métodos e ferra¬ 
mentas para auxiliar na aceitação, na produção, no uso e na manutenção de 
uma arquitetura empresarial. É baseado em um modelo iterativo suportado 
por melhores práticas e por ativos de arquitetura reutilizáveis. 

De acordo com o TOGAF, um framework de arquitetura é uma estrutura 
básica (fundação) ou um conjunto de estruturas que pode ser usado para o 
desenvolvimento de uma gama de arquiteturas de tipos diferentes como a ar¬ 
quitetura empresarial, de sistemas, de aplicações, de dados, de processos, etc. 

Para o TOGAF, o termo arquitetura pode significar: 

□ A descrição formal de um sistema, ou um plano detalhado do sistema 
em nível de componente para guiar a sua implementação. 
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□ A estrutura de componentes, seus relacionamentos, os princípios e as 
orientações que governam seu projeto e a evolução ao longo do tempo. 

Outros objetivos do TOGAF são: 

□ Permitir a implantação da interoperabilidade entre arquiteturas e 
componentes. 

□ Garantir a proteção de ativos que possibilitem a reutilização de com¬ 
ponentes das arquiteturas. 

□ Garantir a reutilização de ativos de processos. 

12 . 5.3 Estrutura do modelo 

A Figura 12.8 apresenta uma visão adaptada dos componentes do TOGAF. 


Necessidades do negócio moldam aspectos não arquiteturais do negócio 


Framework de Capacidade do TOGAF 

| Informa o tamanho, estrutura e cultura 

Framework de Capacidade da 
Arquitetura 
(Parte VII) 


Operação das capacidades da 
arquitetura assegura a realização da 
visão do negócio 


Estabelece metas, KPIs, planos e 
orçamento para os papéis da 
arquitetura 


Direcionadores 
e Visão do 
Negócio 


As necessidades do 
negócio alimentam o 
método, identificando 
problemas para serem 
tratados 


^ A capacidade do negócio direciona a 
necessidade para a maturidade da 
capacidade da arquitetura 


O método refina o 
entendimento das 
necessidades do negócio 


O método produz conteúdo a se 
armazenado no repositório, 
classificado de acordo com o 
Continuum Empresarial 



A capacidade da 
arquitetura opera 

1 um método 

Método de Desenvolvimento da 
Arquitetura (ADM) 

(Parte II) 


Técnicas e Guias de 
Orientação da ADM 
(Parte III) 







O método entrega novas 
soluções para o negócio 


Capacidades do 
Negócio 


Framework de Conteúdo 
da Arquitetura 
(Parte VII) 


TOGAF ADM e 
Framework de Conteúdo 


O Continuum Empresarial 
e o Repositório informam 
o negócio sobre a situação 
atual 


Ferramentas e Continuum 
Empresarial 
(Parte IV) 

Modelos de Referência do 
TOGAF 

[_ (Parte VI) _ J 

Ferramentas e Continuum Empresarial do TOGAF 


Mudanças operacionais 
atualizam o Continuum 
Empresarial e o 
Repositório 


Aprender com as operações do negócio cria novas necessidades de negócio 


Figura 12.8 - Visão geral dos componentes do TOGAF 
Adaptado de The Open Group (2011) 
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O TOGAF é composto por sete partes principais: 

□ A parte I ( Introduction ) fornece uma introdução em alto nível aos con¬ 
ceitos chaves de arquitetura empresarial e à abordagem do TOGAF. 
Contém as definições de termos usados pelo modelo. 

□ A parte II ( Architecture Development Method) apresenta o Método de 
Desenvolvimento de Arquitetura, que é uma metodologia para de¬ 
senvolvimento de arquiteturas empresariais composta por um roteiro 
em etapas. 

□ A parte III ( ADM Guidelines and Techniques ) apresenta a coleção de 
guias de orientação e técnicas disponíveis para aplicar o TOGAF e o 
método ADM. 

□ A parte IV ( Architecture Content Framework ) descreve o conteúdo do 
TOGAF, incluindo um metamodelo estruturado para artefatos de ar¬ 
quitetura, o uso de componentes reutilizáveis da arquitetura e uma 
visão geral dos entregáveis típicos de arquitetura. 

□ A parte V {Enterprise Continuum & Tools ) discute taxonomias apro¬ 
priadas, assim como ferramentas para categorizar e armazenar as saí¬ 
das das atividades de arquitetura dentro de uma empresa. 

□ A parte VI {TOGAFReference Models) fornece uma seleção de modelos 
de arquitetura de referência, que inclui a TOGAF Architecture Founda¬ 
tion e o Integrated Information Infrastructure Reference Model — III-RM. 

□ A parte VII {Architecture Capability Framework ) discute a organiza¬ 
ção, os processos, as habilidades, os papéis e as responsabilidades re¬ 
queridas para estabelecer e operar uma função de arquitetura dentro 
de uma empresa. 

12 . 5.4 Aplicabilidade do modelo 

O TOGAF se aplica para o projeto e a implementação de arquiteturas 
de negócio, de sistemas de informação e de tecnologia. Tais arquiteturas po¬ 
dem ser projetadas e implementadas a partir da arquitetura base do TOGAF 
{Foundation Architecture ) ou de outros padrões da indústria, de fornecedores 
e de ativos de arquitetura que a empresa já possua. 

Como as arquiteturas são baseadas em padrões abertos, permitem a intero¬ 
perabilidade dentro da empresa e entre organizações, atendendo aos requisi¬ 
tos de negócio de integração de serviços entre organizações. 
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No contexto do TOGAF, vários artefatos derivados de modelos de melho¬ 
res práticas como o CobiT, CMMI, ITIL etc. podem estar nos repositórios de 
arquitetura e serem empregados na implementação de arquiteturas relativas a 
processos de TI. 

Acreditamos que o TOGAF possa ser um instrumento útil para os profis¬ 
sionais de arquitetura empresarial nas organizações, incluindo os arquitetos 
de software. Porém, é um modelo relativamente complexo e requer tempo e 
recursos para ser implementado. 

Visto que a cultura empresarial no Brasil é para resultados de curto prazo 
e, para a maioria das empresas, a TI ainda é um custo (e náo investimento), 
acreditamos que sua implementação, apesar de náo ser impossível, vai de¬ 
pender do contexto de cada organização e principalmente do patrocínio da 
administração para que se desenvolvam arquiteturas com base no TOGAF. 


12 . 5.5 Benefícios do modelo 

De acordo com o The Open Group , os benefícios que podem ser obtidos 
com o TOGAF sáo: 

□ Uma operação mais eficiente de TI, visto que uma estrutura mais 
bem definida e a modularidade da infraestrutura de TI levam a uma 
operação muito mais eficiente: 

A Reduzindo custos de desenvolvimento, suporte e manutenção de 
software. 

A Maior portabilidade das aplicações. 

A Melhoria da interoperabilidade. 

A Uma gerência mais fácil de sistemas e de redes. 

A Melhor habilidade para tratar de temas críticos para a organização 
como segurança. 

A Atualizações ( upgrades ) e reaproveitamento de componentes de 
sistemas. 

□ Melhor retorno dos investimentos existentes e redução de riscos para 
futuros investimentos, sendo que as estruturas de sistemas existentes 
e planejados são claramente definidas, levando a: 

A Redução da complexidade da infraestrutura de TI. 
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A Maximização do retorno do investimento da infraestrutura de TI 
existente. 

A Flexibilidade para fazer, comprar ou terceirizar as soluções de TL 
A Reduzir o risco total em novos investimentos e os custos totais de 
propriedade 118 de TI. 

□ Aquisições mais rápidas, fáceis e baratas, pois há uma estratégia clara 
para aquisições e migrações futuras, resultando em: 

A Decisões de compras mais simples, em virtude das informações que 
governam as aquisições estarem disponíveis em um plano coerente. 
A O processo de aquisição é mais rápido, sem o sacrifício da coerên¬ 
cia com a arquitetura. 

□ Flexibilidade para o crescimento e a reestruturação do negócio, pois 
é mais fácil assegurar acesso a informações integradas por toda a 
organização: 

A Maximização da flexibilidade para o crescimento e a reestrutura¬ 
ção do negócio. 

A Ganhos reais com a diminuição dos gastos em processos de reen- 
genharia do negócio, consolidações internas, fusões e aquisições. 

□ Tempo para chegar no mercado mais rápido (melhor time-to-market), 
visto que a infraestrutura de TI está mais bem equipada para a implan¬ 
tação de aplicações de missão crítica de forma mais rápida e segura: 
A Time-to-market mais rápido para novos produtos e serviços. 

A Aumento do crescimento e da rentabilidade do negócio. 

12 . 5.6 Certificações relacionadas 

O The Open Group mantém várias certificações, e uma delas é justamente 
a certificação em TOGAF. Este certificado tem foco no profissional e em trei¬ 
nadores. O The Open Group também mantém um esquema de licenciamento 


118 Custo total de propriedade (ou Total Cost of Ownership - TCO) é o custo total de um componente 
da infraestrutura ao longo de sua vida útil. Esta métrica considera todos os custos associados a esse 
componente, incluindo os custos de aquisição e de manutenção, treinamento, reposição de peças, 
depreciação, seguros, consumo de energia, quebras etc. 
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de produtos e serviços relativos ao TOGAF para fornecedores de soluções, 
treinamentos etc. 

Há dois tipos de certificação para o profissional: 

□ TOGAF 9 Foundation -, valida se o candidato tem conhecimento da 
terminologia e dos conceitos básicos do modelo e compreende os 
princípios básicos da arquitetura empresarial. Requer um aproveita¬ 
mento de 55% em quarenta questões de múltipla escolha. 

□ TOGAF 9 Certiíied -. em adiçáo ao conhecimento e à compreensão, o 
candidato é apto a analisar e aplicar o TOGAF. O exame compreende 
oito questões de cenários, sendo que a resposta correta vale 5 pontos, 
a segunda melhor resposta vale 3 pontos e a terceira melhor 1 ponto. 
Para passar, o candidato deve ter um aproveitamento de 60% (24 
pontos em 40). 

Os exames podem ser realizados em um centro Prometric credenciado. 


12.6 ISO 9001:2008 

12 . 6.1 Visão geral do modelo 

A ISO 9001:2000 é uma evolução do conjunto de normas ISO 9000 es¬ 
tabelecido no início da década de 90 e que era constituído pela ISO 9000, 
9001, 9002, 9003 e 9000-3 (esta última rege a aplicação da ISO 9001 para 
atividades de desenvolvimento de software). 

Atualmente, há somente a ISO 9001, que se aplica tanto a empresas ou 
atividades de serviços como de manufatura e é orientada para sistemas da qua¬ 
lidade que têm por objetivo a geração de produtos e/ou serviços, de acordo 
com os requisitos dos clientes. Nesse sentido, abrange todo o ciclo de vida de 
um produto ou serviço, desde a sua concepção até a sua desmobilização. 

Em 2008, esta norma foi aperfeiçoada visando maior clareza, facilidade 
de localização em outros idiomas e também a compatibilidade com a norma 
ISO 14001:2004. Entretanto, as características essenciais da norma (mode¬ 
lo de processos, estrutura, abordagem por processos, campo de aplicações) 
mantiveram-se inalteradas na ISO 9001:2008. 

Esta norma especifica requisitos para um sistema de gestão da qualidade, 
quando uma organização: 
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a) Necessita demonstrar sua capacidade para fornecer, de forma coe¬ 
rente, produtos que atendam aos requisitos do cliente e requisitos 
regulamentares aplicáveis. 

b) Pretende aumentar a satisfação do cliente por meio da efetiva aplica¬ 
ção do sistema, incluindo processos para melhoria contínua do sis¬ 
tema e a garantia da conformidade com os requisitos do cliente e 
requisitos regulamentares aplicáveis. 

Todos os requisitos desta norma são genéricos. Pretende-se que tais requisi¬ 
tos sejam aplicáveis a todas as organizações, sem levar em consideração o tipo, 
o tamanho e o produto fornecido. Quando alguns dos requisitos não pude¬ 
rem ser aplicados, devido à natureza de uma organização e seus produtos, isso 
pode ser considerado para exclusão. 

A norma aplica totalmente os princípios da Gestão da Qualidade Total, 
usando fortemente o ciclo de Deming, ou seja, Plan-Do-Check-Act. A Figura 
12.9 mostra a filosofia que governa esta norma. 


Melhoria contínua do Sistema de Gestão da Qualidade 


CLIENTES 
(e outras 
partes 

interessadas) 


Requisitos 



Figura 12.9 - Modelo de melhoria da ISO 9001 
Adaptado de ISO (2008) 


Esta norma é composta pelos seguintes elementos: 
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Sistema de Gestão da Qualidade 


A organização deve: 

□ Identificar os processos necessários para o sistema de gestão da quali¬ 
dade e sua aplicação por toda a organização. 

□ Determinar a sequência e a interação desses processos. 

□ Determinar critérios e métodos necessários para assegurar que a ope¬ 
ração e o controle desses processos sejam eficazes. 

□ Assegurar a disponibilidade de recursos e informações necessárias 
para apoiar a operação e o monitoramento desses processos. 

□ Monitorar, medir e analisar esses processos. 

□ Implementar ações necessárias para atingir os resultados planejados e 
a melhoria contínua desses processos. 


Requisitos de documentação 


O sistema da qualidade deve ter os seguintes documentos: 

□ Declarações documentadas de uma política da qualidade e dos obje¬ 
tivos da qualidade. 

□ Um manual da qualidade. 

□ Procedimentos documentados e registros requeridos pela norma. 

□ Documentos (incluindo registros) determinados pela organização 
como necessários para o planejamento, a operação e o controle efica¬ 
zes de seus processos. 


Responsabilidade da direção 


O sistema da qualidade exige os seguintes requisitos que demonstram o 
envolvimento, o patrocínio, o comprometimento e a responsabilidade da di¬ 
reção com relação a: 

□ Comunicar à organização a importância de atender aos requisitos dos 
clientes, como também aos requisitos estatutários e regulamentares. 
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□ Estabelecer a política da qualidade. 

□ Assegurar que os objetivos da qualidade sejam estabelecidos. 

□ Conduzir as análises críticas da direção. 

□ Assegurar a disponibilidade de recursos. 

□ Assegurar que: 

A os requisitos dos clientes sejam determinados e atendidos com o 
propósito de aumentar a satisfação dos clientes; 

A a política da qualidade seja adequada à organização; 

A os objetivos da qualidade sejam estabelecidos nas funções e nos 
níveis pertinentes da organização; 

A as autoridades e responsabilidades sejam definidas e comunicadas 
por toda a organização. 

□ Indicar um representante que assegure que os processos de gestão da 
qualidade sejam estabelecidos, implementados e mantidos. 

□ Estabelecer os processos de comunicação adequados. 

□ Analisar criticamente o sistema de gestão da qualidade. 


stao 


de recursos 


A organização deve prover os recursos necessários para implementar e man¬ 
ter o sistema de gestão da qualidade, melhorar continuamente sua eficácia e 
aumentar a satisfação do cliente. 

□ Competência, treinamento e conscientização. 

□ Infraestrutura para alcançar a conformidade com os requisitos do 
produto. 

□ Ambiente de trabalho para alcançar a conformidade com os requisi¬ 
tos do produto. 


ização do produto 


Contempla: 

□ O planejamento da realização do produto. 

□ Processos relacionados a clientes. 
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□ Projeto e desenvolvimento. 

□ Aquisição. 

□ Produção e prestação de serviço. 

□ Controle de equipamento de monitoramento e medição. 


Medição, análise e melhoria 


Contempla: 

□ Monitoração e medição. 

□ Controle de produto não conforme. 

□ Análise de dados. 

12 . 6.2 Aplicabilidade do modelo 

O modelo pode ser aplicado a qualquer tipo de operação ou negócio que 
resulta em um produto ou em um serviço. 

No caso específico da área de TI, podemos aplicá-lo em operações de desen¬ 
volvimento de sistemas, de suporte, de infraestrutura e assim sucessivamente. 

Esta norma é passível de certificação por parte de uma entidade credencia¬ 
da, geralmente uma empresa de auditoria de sistemas da qualidade. A certifi¬ 
cação tem reconhecimento mútuo, ou seja, por várias entidades credenciado- 
ras no Brasil (tais como o Inmetro) e em outros países. 

A auditoria, neste caso, é caracterizada como de terceira parte, pois 
é a organização postulante que deve contratar a entidade que realizará a 
auditoria. 

O sistema da qualidade recebe uma auditoria de manutenção a cada seis 
meses e, ao final de três anos, a organização deve passar por uma nova cer¬ 
tificação de revalidação. Nessa auditoria de revalidação, espera-se que tenha 
havido progresso na melhoria contínua do sistema da qualidade. 

Esta norma pode ser combinada perfeitamente com o CMMI e o PMBOK, 
no caso de desenvolvimento de software, e também com outros modelos já 
mencionados neste livro, voltados para processos de TI em geral. 
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12.7 ISO 31000 

12 . 7.1 Visão geral do modelo 

A ISO 31000 - Risk management — principies and guidelines tem como 
escopo o gerenciamento de riscos e se aplica a qualquer tipo de organização 
(privadas, públicas e terceiro setor), no contexto de decisões, estratégias, ope¬ 
rações, processos, funções, projetos, produtos, serviços e ativos. Esta norma 
não é objeto de certificação. 

A norma é composta por três componentes, um conjunto de princípios, 
um frameivork e um processo para o gerenciamento dos riscos. 

A Figura 12.10 mostra o relacionamento entre esses componentes. 

Os princípios para o gerenciamento de riscos são: 

□ O gerenciamento de riscos cria e protege o valor para objetivos de au¬ 
mento de desempenho em segurança e saúde das pessoas, compliance, 
proteção ambiental, eficiência de operações e serviços etc. 

□ O gerenciamento de riscos é parte integral de todos os processos da 
organização. 

□ O gerenciamento de riscos é parte do processo de tomada de decisão. 



Figura 12.10 - Modelo de riscos ISO 31000 
Adaptado de ISO (2009) 
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□ O gerenciamento de riscos trata, explicitamente, da incerteza. 

□ O gerenciamento de riscos é sistemático, estruturado e realizado nos 
tempos requeridos. 

□ O gerenciamento de riscos é baseado na melhor informação disponível. 

□ O gerenciamento de riscos é “customizado”. 

□ O gerenciamento de riscos leva em consideração fatores humanos e 
culturais. 

□ O gerenciamento de riscos é transparente e inclusivo. 

□ O gerenciamento de riscos é dinâmico, iterativo e responsivo à mudança. 

□ O gerenciamento de riscos facilita a melhoria contínua da organização. 

O framework é a base para o gerenciamento dos riscos na organização em 
todos os níveis e também serve para que seja integrado ao seu sistema de ges¬ 
tão. Os elementos desse framework são: 

□ Mandato e comprometimento: a implantação de um sistema de 
gerenciamento de riscos requer o comprometimento dos executivos 
da organização e da alta administração. Deve estabelecer políticas, 
alinhar a cultura, determinar indicadores de riscos, alinhar com os 
objetivos estratégicos da organização, assegurar compliance etc. 

□ Projeto do framework para o gerenciamento de riscos: compre¬ 
ende o entendimento da organização e de seu contexto, o estabeleci¬ 
mento de uma política para o gerenciamento de riscos, a atribuição 
de responsabilidades pelo gerenciamento e pela prestação de contas, a 
integração nos processos da organização, a alocação de recursos para 
o gerenciamento dos riscos, o estabelecimento dos mecanismos de 
reporte e os mecanismos de comunicação externa. 

□ Implementação do gerenciamento de riscos: compreende a imple¬ 
mentação do framework , a implementação dos processos de gerencia¬ 
mento de riscos, o monitoramento, a revisão e a melhoria contínua 
do framework. 

Os processos de gerenciamento de riscos devem ser parte integrante do 
gerenciamento da organização, assim como devem estar embutidos na cultu¬ 
ra e nas práticas da organização e adaptados para os processos de negócio da 
organização. Tais processos são: 
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□ Comunicação e consultoria: compreende entender os requisitos dos 
interessados relevantes, internos e externos, assim como da equipe 
que vai auxiliar na definição do contexto dos riscos, assegurar que 
os requisitos dos interessados relevantes sejam considerados e que os 
riscos sejam identificados corretamente, trazer expertise multidiscipli- 
nar para a análise dos riscos, assegurar que diferentes pontos de vista 
sejam usados para definir critérios de riscos e sua avaliação e obter 
apoio para planos de tratamento dos riscos. 

□ Estabelecimento do contexto: compreende o estabelecimento do 
contexto do ambiente externo e interno da organização que pode 
afetar a identificação dos riscos para o atendimento aos objetivos 
da organização. Pode incluir variáveis políticas, econômicas, cultu¬ 
rais, regulatórias, estruturais e políticas da organização, assim como 
sistemas de informação, padrões, normas etc. Também contempla 
o estabelecimento do contexto do processo de gerenciamento de 
riscos em termos de definir os objetivos e as metas das atividades 
de gerenciamento de riscos, responsabilidades, escopo, metodologia 
de avaliação de riscos, forma de medir o desempenho e, por fim, 
definir os critérios de riscos. 

□ Avaliação dos riscos: compreende a identificação dos riscos, sua aná¬ 
lise e avaliação. 

□ Tratamento dos riscos: compreende a avaliação das alternativas de 
tratamento de riscos, o nível de tolerância dos riscos residuais (riscos 
que persistem após a aplicação do tratamento selecionado) e a avalia¬ 
ção da eficácia do tratamento selecionado. 

□ Monitoramento e revisão: compreende o monitoramento e o acom¬ 
panhamento dos processos e dos riscos. Assegura que os controles 
estão funcionando bem, se novos riscos estão surgindo, registra lições 
aprendidas e monitora mudanças nos contextos internos e externos 
que podem afetar os riscos que estão sendo gerenciados. 

□ Registros do processo de gerenciamento de riscos: refere-se ao tra¬ 
tamento a ser dado aos registros gerados pelo processo, à determina¬ 
ção de quem pode ter acesso, quais informações são sigilosas, necessi¬ 
dades de compliance, períodos de retenção dos registros etc. 
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12 . 7.2 Aplicabilidade do modelo 

Este modelo se aplica perfeitamente ao gerenciamento de riscos que a TI 
oferece para o negócio. 

Geralmente, esta norma pode ser aplicada para um sistema de gerencia¬ 
mento de riscos corporativo, no qual o sistema de gerenciamento de riscos da 
TI pode estar embutido. 

Em grandes organizações, os riscos dos processos de negócios sáo mapea¬ 
dos, inclusive os riscos de TI. O gerenciamento dos riscos de TI pode ser feito 
a partir desses mapas de riscos dos processos do negócio. 

Acreditamos que esta seja a abordagem mais adequada, pois permite focar 
nos maiores riscos que a TI representa para o negócio. 



D 


Extensões e Derivações do Conceito 
de Governanç a de TI 


A Governança de TI aborda uma gama de preceitos, definições, proces¬ 
sos, premissas e modelos no âmbito geral da TI. Nesse contexto, existe um 
vasto campo onde tais princípios podem ser derivados e/ou estendidos para 
disciplinas específicas, que estejam de alguma forma inscritas ou correla¬ 
cionadas com a TI. Este capítulo traz uma breve visão acerca de algumas 
delas: Governança de Processos, Governança SOA e Governança de Dados. 


13.1 Governança de Processos 

13 . 1.1 Princípios e conceitos gerais 

A disciplina de Gestão de Processos de Negócio está fortemente ligada 
às disciplinas que constituem o contexto da Governança de TL Na grande 
maioria das vezes, a dinâmica de gerenciamento do portfólio de TI (projetos, 
processos, serviços, ativos) é conduzida para atender às demandas por proces¬ 
sos de negócio novos ou melhorados, visando ao atingimento dos objetivos 
estratégicos da organização. 

Segundo Paim et al (2009), os processos de negócio possuem uma natureza 
sistêmica e estão estreitamente relacionados com alguns elementos conceitu¬ 
ais, que devem ser levados em consideração em todos os momentos do seu 
ciclo de vida de gerenciamento: 


□ Estratégia: direciona os processos organizacionais, pois estabelece os 
objetivos de mais alto nível, guiando a adoção de cursos de ação e a 
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alocação de recursos para atingi-los. Serve como orientação para o 
trabalho gerencial e operacional cotidiano e pode induzir um padrão 
de ações e decisões coerentes entre si para alcançar um determinado 
desempenho desejado. 

□ Estrutura organizacional: é através dela que os processos de negócio 
são executados e gerenciados. Em grande parte das organizações, essa 
estrutura é tradicionalmente familiar; entretanto, têm sido identifi¬ 
cadas no mercado iniciativas de redesenho da estrutura para priorizar 
o eixo de processos na busca por maior agilidade, flexibilidade e in¬ 
tegração. Entre essas iniciativas, figuram a estruturação por processos 
(transversal) complementando a estruturação funcional, o estabeleci¬ 
mento de mecanismos de coordenação lateral (permeando as várias 
áreas funcionais) para suportar a gestão dos processos transversais, a 
criação de mecanismos de decisão que lidem com os conflitos que 
surgem quando há dois eixos de gestão, a formação de grupos para 
gerenciar processos do início ao fim etc. O Escritório de Processos 
surge como uma unidade que pode atuar em caráter normativo e/ou 
coordenador dentro deste contexto. 

□ Indicadores de desempenho: o desempenho de uma organização é 
resultante de uma equação construída sobre o desempenho de todos 
os seus processos de negócio. É importante que seja estabelecido um 
conjunto de medições que possa prover uma visão do desempenho 
dos processos desde o nível operacional (tempos, custos, esforço, qua¬ 
lidade etc.) até o nível estratégico (influência dos processos trans¬ 
versais nos resultados globais do negócio da organização), passando 
pelos aspectos gerenciais e de interação entre as várias unidades fun¬ 
cionais envolvidas. 

□ Competências: processos e suas atividades possuem requisitos de 
competência (conhecimentos formais, experiências/habilidades e 
atitudes) necessários para a sua execução e gestão. Por sua vez, cada 
indivíduo possui um conjunto de competências desenvolvidas e po¬ 
tenciais. Encontrar perfis adequados para desempenhar cada ativida¬ 
de dentro de um processo requer um método para mapear as com¬ 
petências necessárias e as disponíveis na organização e criar novas 
capacitações para o preenchimento das lacunas que eventualmente 
possam existir. 
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□ Ativos de informação e conhecimento: processos geram dados, in¬ 
formações e conhecimentos e dependem deles também. Processos 
que forem mais dependentes de dados (registros puros) e infor¬ 
mações (mensagens com algum significado) sáo aqueles onde a 
utilização da TI para automação pode obter maiores resultados. 
Já aqueles processos que se baseiam fortemente no conhecimento 
(crenças, interpretação das informações) possuem maior depen¬ 
dência de atividades humanas e, portanto, são menos sujeitos à 
automação. 

□ Tecnologia da informação: a TI pode ser considerada a grande via- 
bilizadora das iniciativas de processos nas organizações, permitindo 
a integração dos fluxos de informação entre os processos e as várias 
funcionais que eles atravessam, dessa forma viabilizando a escalada 
da execução e da gestão dos processos para maiores grupos, maiores 
distâncias, maior quantidade de situações etc. Entre as iniciativas de 
TI mais frequentes estão a implementação de sistemas do tipo ERP 
(Enterprise Resource Planning ), BPMS ( Business Process Management 
Systems ), ECM ( Enterprise Content Management) etc. e a criação de 
arquiteturas corporativas. 

□ Cultura organizacional: pode ser vista como um “pano de fundo” 
para a relação entre os demais elementos citados, a partir da visão dos 
processos, representando um modelo em camadas. Nas camadas mais 
internas estão os aspectos menos acessíveis, tais como crenças, pensa¬ 
mentos e sentimentos; nas camadas mais externas estão os produtos, 
serviços e padrões existentes (ou seja, o que se pode ver); nas camadas 
intermediárias, estão as estratégias, filosofias e os objetivos da organi¬ 
zação, como valores que influenciam e governam o comportamento 
da organização. 

A governança tem sido apontada por diversos autores como uma ferra¬ 
menta importante para auxílio à gestão empresarial, que, por meio de papéis 
e mecanismos alinhados à estratégia, atua como orientadora para a Gestão de 
Processos em uma organização. Vejamos alguns exemplos de definições para 
Governança de Processos. 

Segundo Harmon (2008), a governança é “a organização do gerenciamen¬ 
to e refere-se aos objetivos, princípios e mapas organizacionais que definem 
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quem pode tomar quais decisões, assim como as políticas e regras que definem 
ou restringem o que os gerentes podem fazer”. A governança difere da Gestão 
de Processos, pois esta preocupa-se mais com as atividades do dia a dia dos 
processos. 

Harmon (2007) sustenta que “o papel da Governança de Processos é ga¬ 
rantir que os gestores de processos assumam a responsabilidade pelo desem¬ 
penho dos processos da organização”. 

Para Jeston & Nelis (2008), a Governança de Processos consiste em um 
“instrumento que garante o bom desempenho dos processos, dos projetos de 
processos e da estratégia, assim como o alinhamento de todos eles entre si”. O 
seu foco deve estar nos seguintes elementos-chave: 

□ Processos de tomada de decisão relacionados à gestão dos processos. 

□ Definição dos papéis e das responsabilidades em todo o ciclo da ges¬ 
tão de processos. 

□ Relação das métricas dos processos com os critérios de desempenho e 
os objetivos estratégicos da organização. 

□ Definição, documentação e disseminação de padrões corporativos 
para a gestão de processos (incluindo questões como medições, solu¬ 
ção de problemas, estruturas de recompensa etc.). 

□ Estabelecimento de controles para a gestão de processos, para garan¬ 
tia da manutenção dos princípios dos processos e das questões de 
compliance. 

Richardson (2006) define Governança de Processos como “um conjunto 
de regras que estabelecem ou governam a forma como uma organização deve 
conduzir uma determinada função do negócio” e “um conjunto de diretrizes 
e recursos que uma organização utiliza para facilitar a colaboração e a comu¬ 
nicação durante a execução de iniciativas de processos”. 

Por fim, para Barros (2009), Governança de Processos é “um framework que 
organiza e define os elementos: papéis e responsabilidades, padrões, tarefas, 
estrutura organizacional, objetivos, mecanismos de controle e mecanismos 
de avaliação, de forma a viabilizar a Gestão de Processos como elemento de 
gestão cotidiano nas organizações com o objetivo de melhorar a performance 
de seus processos”. 
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13 . 1.2 Modelos de referência relacionados 

Alguns modelos de referência existentes fazem referência, direta ou indire¬ 
tamente, à Governança de Processos. Dentre eles, o BPM CBOK® (já abor¬ 
dado anteriormente neste livro) possui duas áreas de processo cujas práticas 
envolvem atividades de governança: Organização de Gerenciamento de Pro¬ 
cessos e Gerenciamento de Processos Corporativos. 

Dois aspectos importantes relacionados à governança sáo o alinhamento 
com a estratégia organizacional e a definição de uma arquitetura de proces¬ 
sos consistente e adequada aos objetivos estratégicos. Modelos de referência 
como o Balanced Scorecard , o SCOR (desenvolvido pelo Supply Chain Coun- 
cil) e o eTOM (fornecido pelo TeleManagementForum, um consórcio de em¬ 
presas de telefonia) são bastante úteis para facilitar a criação, a manutenção e 
a decomposição de uma cadeia de valor em processos e subprocessos. 

Existem também alguns modelos cujo foco está na avaliação e constatação 
da maturidade organizacional em Gestão de Processos de Negócio. Por exem¬ 
plo, o OMG ( Object Management Group) lançou em 2008 o BPMM ( Business 
Process Maturity Mo dei), fortemente inspirado no CMM, que descreve um 
caminho de melhoria que orienta as organizações na direção de processos 
cada vez mais maduros e disciplinados. Segundo o OMG (2008), são cinco os 
níveis de maturidade que uma organização pode atingir em relação à Gestão 
de Processos: 

□ Nível 1 - Inicial: esforços individuais sem processos ou suporte orga¬ 
nizacional explícito, com resultados imprevisíveis. 

□ Nível 2 - Gerenciado: gerentes asseguram um ambiente de tra¬ 
balho estável e repetível em cada unidade de trabalho. Diferen¬ 
tes unidades podem ter procedimentos diferentes para atividades 
similares. 

□ Nível 3 - Padronizado: processos padrão e criação de ativos para rea¬ 
lizar o produto e/ou o serviço de forma customizada. Foco na econo¬ 
mia de escala e no aprendizado. 

□ Nível 4 - Previsível : processos gerenciados quantitativamente para 
obtenção de resultados previsíveis. 

□ Nível 5 - Inovador: processos melhorados continuadamente e busca 
de inovação para reduzir os gaps de capacidade da organização. 
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Jeston & Nelis (2008) abordam também alguns modelos de maturidade e 
estabelecem seis fatores críticos para a disciplina de BPM, que precisam estar 
em ordem para que as iniciativas de gerenciamento de processos da organiza¬ 
ção sejam bem-sucedidas. Cada um desses fatores foi detalhado em elementos 
denominados “Áreas de Capacitação”, que devem ser endereçadas em cada 
nível de maturidade. A avaliação dessas áreas de capacitação, complementada 
pela análise de documentos relacionados à gestão de processos, pode facilitar 
o entendimento do estágio atual da organização na disciplina de BPM. A Fi¬ 
gura 13.1 mostra essa relação entre fatores e áreas de capacitação, dentro do 
modelo BPMM proposto por esses autores. 



Figura 13.1 - Áreas de capacitação em BPM 
Adaptado de Jeston & Nelis (2008) 


Uma outra abordagem bastante interessante e abrangente é o modelo teó¬ 
rico para a Governança de Processos proposto por Barros (2009) a partir de 
uma análise comparativa de várias abordagens e definições, que consiste na 
reunião do seguinte conjunto de elementos inter-relacionados, no âmbito da 
gestão de processos: 
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□ Papéis e Responsabilidades: é importante que sejam definidos papéis 
que atuem dentro da estrutura organizacional como responsáveis em 
tarefas específicas na gestão de processos, tais como gestor de proces¬ 
so, chefe do escritório de processos, analista de processo, patrocina¬ 
dor, gestor de projeto, analista de TI etc. 

□ Padrões: destinam-se a dar um grau de uniformidade à gestão de 
processos nas organizações, podendo ser adotados para fatores como 
ferramentas (que suportem a automação de tarefas específicas), ar¬ 
quitetura de processos (hierarquias e tipos de representação gráfica), 
métodos (que propõem a forma como executar alguma tarefa - por 
exemplo, BPMN para modelar processos), métricas (para acompa¬ 
nhar o desempenho dos processos) e documentos (que orientam a 
execução das tarefas pelos seus responsáveis). 

□ Estrutura: deve ser estabelecida uma estrutura organizacional que 
contemple os responsáveis pelas tarefas de gestão de processos, tais 
como o Escritório de Processos (como elemento normatizador e con¬ 
trolador), o Gestor de Processos (como mentor e mantenedor dos 
processos), o Comitê de Processos (como viabilizador estratégico) e o 
Gestor de Projetos (como implementador dos processos). 

□ Tarefas: devem ser definidas e atribuídas a algum papel, que, por sua 
vez, está alocado em algum local da estrutura organizacional. 

□ Objetivos: devem ser definidos quais objetivos a organização espera 
atingir com a adoção da gestão de processos (por exemplo, agilidade, 
nível de serviço para os clientes, desempenho operacional, compliance 
etc.). 

□ Mecanismos de Controle: servem para verificar se o modelo de go¬ 
vernança está funcionando adequadamente e auxiliam o seu aper¬ 
feiçoamento e evolução (por exemplo, podem ser adotados ciclos de 
revisão, regras de compliance etc.). 

□ Mecanismos de Avaliação: servem para avaliar o desempenho dos en¬ 
volvidos na gestão de processos na execução de suas tarefas, sob a 
ótica dos processos. 

A Figura 13.2 ilustra o modelo proposto por Barros (2009): 
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5 - MECANISMOS DE 
CONTROLE 


6-OBJETIVOS 


7 - MECANISMOS DE 
AVALIAÇÃO 


Figura 13.2 - Um modelo de Governança de Processos 
Adaptado de Barros (2009) 


13 . 1.3 Aplicabilidade do conceito 

O termo “governança” está relacionado ao estabelecimento de responsabi¬ 
lidades claras e transparentes, assim como de processos de tomada de decisão 
para garantir o alinhamento com os objetivos estratégicos da organização. 

Por meio da Governança de Processos, é possível estruturar e gerenciar 
processos de forma a atender aos objetivos de negócio e a criar valor para a 
organização. Adicionalmente, os princípios de governança facilitam o enten¬ 
dimento das interações entre as áreas, dos papéis e responsabilidades de cada 
ator na organização, dos impactos e riscos inerentes aos processos, dos requi¬ 
sitos de compliance para os processos e do valor agregado aos clientes pelos 
produtos e serviços gerados pelos processos. 
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Projetos e iniciativas de gestão de processos de negócio estão forte¬ 
mente ligados à garantia da viabilidade do negócio, assim como a ações 
de otimização do desempenho durante todo o ciclo de vida dos proces¬ 
sos. Frequentemente, tais ações são implementadas por meio de progra¬ 
mas e/ou projetos de TI, envolvendo atividades multidisciplinares que 
requerem mecanismos de coordenação que atravessam várias estruturas 
organizacionais. 

Nesse sentido, pode-se dizer que a Governança de Processos e a Governan¬ 
ça de TI estão fortemente relacionadas entre si. Uma vez que os processos de 
TI são, na maioria das vezes, processos de apoio na cadeia de valor de uma 
organização 119 , os mesmos princípios podem ser aplicados em ambos os contex¬ 
tos. Vários dos modelos de referência aplicáveis em processos de TI podem ser 
aplicados também a processos de negócio (por exemplo, temos visto com fre¬ 
quência a utilização de boas práticas da ITIL na implementação e automação 
de processos de áreas de negócio fora da TI, tais como Recursos Humanos, 
Logística etc., que fornecem serviços aos clientes externos e às demais áreas 
da organização). 

Uma das abordagens que tem sido cada vez mais frequente é a criação de 
áreas e/ou equipes especialistas de BPM, tais como Escritórios de Processos, 
Comitês de Processos, Centros de Excelência etc. Tais estruturas podem atuar 
como facilitadoras, estimuladoras, controladoras ou até mesmo executoras de 
atividades de BPM (na forma de projetos e/ou ações continuadas) em uma 
organização. 


13 . 1.4 Certificações relacionadas 

O programa CBPP® (Certified Business Process Professionat ) 120 abrange áreas 
de conhecimento do BPM CBOK® que estão diretamente relacionadas à Go¬ 
vernança de Processos (Organização de Processos de Negócio e Gerenciamen¬ 
to de Processos Corporativos). 


119 Quando a organização tem produtos ou serviços de TI como o núcleo de seu negócio, os processos 
de TI podem ser considerados processos finalísticos. 

120 Ver seção sobre o modelo de referência BPM CBOK®. 
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13.2 Governança SOA 


NOTA: esta seção é uma contribuição do consultor Antonio Carlos 
Abuhab Fernandes, especialista em projetos e iniciativas utilizando o para¬ 
digma SOA {Service-Oriented Architecture ). 


13 . 2.1 Princípios e conceitos gerais 

13.2.1.1 Computação Orientada a Serviços 

A computação orientada a serviços representa uma nova geração da plata¬ 
forma de computação distribuída, incluindo seus próprios paradigmas, prin¬ 
cípios, padrões de projeto, linguagens, modelo arquitetural distinto, concei¬ 
tos, tecnologias e frameworks relacionados. 

A computação orientada a serviços baseia-se em plataformas de compu¬ 
tação distribuídas já utilizadas em larga escala pela indústria de tecnologia, 
adicionando novas camadas de projeto e considerações de governança, além 
de um vasto conjunto de implementações tecnológicas. 

A computação orientada a serviços é composta pelos seguintes elementos: 

□ Service- Orien te d Arcbitecture. 

□ Service-Orientation. 

□ Service-Oriented Solution Logic. 

□ Services. 

□ Service Compositions. 

□ Service Inventory. 

13.2.1.2 SOA 

De acordo com Erl (2008), Service-Oriented Arcbitecture (SOA) estabelece 
um modelo arquitetural que visa aumentar a eficiência, agilidade e produti¬ 
vidade de uma empresa pelo posicionamento de serviços como o principal 
meio através do qual a solução lógica é representada no apoio à realização dos 
objetivos estratégicos associados à computação orientada a serviços. 





Extensões e Derivações do Conceito de Governança de TI 515 


Em uma base fundamental, a plataforma de computação orientada a servi¬ 
ços gira em torno do paradigma do projeto orientado a serviço e sua relação 
com a arquitetura orientada a serviços. O termo Service-OrientedArchitecture 
e seu acrônimo foram amplamente utilizados pela mídia e pela literatura de 
marketing de fornecedores, onde SOA quase se tornou sinônimo de compu¬ 
tação orientada a serviços em si. Portanto, é muito importante deixar claro 
que existe distinção entre o que é SOA e como SOA se relaciona com outros 
elementos da computação orientada a serviços. 

Como uma forma de arquitetura tecnológica, uma implementação SOA 
pode consistir de uma combinação de tecnologias, produtos, APIs, extensões 
de infraestrutura de apoio e diversas outras partes. A face real de uma arquite¬ 
tura orientada a serviços implantada é única dentro de cada empresa. No en¬ 
tanto, SOA é caracterizada pela introdução de novas tecnologias e plataformas 
que suportam especificamente a criação, a execução e a evolução de soluções 
orientadas a serviços. Como resultado, a construção de uma arquitetura de 
tecnologia em torno do modelo de arquitetura orientada a serviços estabelece 
um ambiente adequado para a solução lógica que foi projetada em conformi¬ 
dade com os princípios de projeto orientado a serviço. 


13.2.1.3 Desafios e metas de uma implantação SOA 

Conforme The Open Group (2009), a implantação SOA possui uma série 
de desafios, tais como: 

□ Identificação do serviço. 

□ Gerenciamento do portfólio de soluções SOA. 

□ Demonstrar benefícios de soluções SOA. 

□ Garantir que os serviços satisfaçam os requerimentos de negócio. 

□ Gerenciamento do serviço. 

□ Financiamento do serviço. 

□ Propriedade do serviço. 

□ Integração de serviços baseados na web. 

□ Ausência de interoperabilidade dos serviços. 

□ Reutilização apropriada. 

□ Proliferação descontrolada de serviços. 

□ Múltipl os silos de SOA. 
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□ Coordenação cross-organization. 

□ Gerenciamento de mudança de serviços e soluções. 

Uma implantação SOA aumenta a importância de endereçar os desafios 
citados, muitos deles enfrentados por anos pelos departamentos de tecnologia 
das organizações, como, por exemplo, modelos de financiamento, proprieda¬ 
de funcional, padrões e conformidade. 

Portanto, as organizações devem garantir que: 

□ Serviços e soluções corretas são construídos a fim de atender às neces¬ 
sidades de negócio. 

□ Há uma abordagem consistente de descoberta, consumo, identifica¬ 
ção, projeto, desenvolvimento, implementação e gerenciamento de 
serviços e soluções. 

□ As decisões apropriadas de linha de negócio da organização são 
tomadas. 

□ A abordagem SOA está sendo comunicada adequadamente por toda 
a organização. 

□ Treinamentos adequados de SOA são realizados pela organização. 

□ A arquitetura de referência SOA torna-se relevante para a organização. 

□ Serviços são financiados e sua propriedade documentada. 

□ Somente serviços aprovados são implantados. 

□ Os serviços são criados em concordância com as políticas de governança. 

□ Os serviços são projetados, construídos e executados de maneira 
segura. 

□ As mudanças nos serviços são gerenciadas. 

□ Os serviços são gerenciados de uma forma escalável. 

□ Desenvolvedores de serviços podem publicar e descobrir serviços 
facilmente. 

□ SLAs existentes são validados quando novos consumidores são 
adicionados. 

□ Os controles de governança SOA e a política de exceção existem e são 
efetivas. 

□ Os papéis apropriados e pragmáticos da governança SOA, responsa¬ 
bilidades e autoridade estão entendidos e sendo executados de forma 
aceitável. 
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□ Há vitalidade no processo de governança, ou seja, a governança SOA 
amadurece de acordo com o amadurecimento das capacidades SOA 
da organização. 


13.2.1.4 Governança SOA 

De acordo com The Open Group (2009b), governança significa estabelecer 
e aplicar processos de modo que pessoas e soluções trabalhem juntas para 
atingir os objetivos organizacionais. O foco em adicionar controles distingue 
governança das atividades de gerenciamento do dia a dia. 

A governança SOA deve ser vista como a aplicação da governança de ne¬ 
gócio, da Governança de TI e da governança de arquitetura empresarial com 
ênfase na arquitetura orientada a serviços (SOA). 

Portanto, a governança de SOA é uma extensão das governanças de TI e 
de arquitetura empresarial (EA), assegurando que os benefícios de SOA sejam 
atingidos. Isso exige governar não apenas os aspectos da execução SOA, mas 
também as atividades de planejamento estratégico. A Figura 13.3 mostra esses 
relacionamentos. 
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Figura 13.3 - Relacionamentos da Governança SOA 
Adaptado de The Open Group (2009b) 
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13.2.1.5 Escopo da governança SOA 

Como abordadas anteriormente, muitas das definições iniciais de SOA 
eram extremamente focadas em tecnologia, e as diferenças entre SOA e a tec¬ 
nologia web Services eram obscuras. Um dos efeitos colaterais dessa definição 
é o equívoco de pressupor que a governança SOA pode ser resolvida apenas 
pela tecnologia. 

Governança SOA exige igual foco em pessoas, processos e aspectos tec¬ 
nológicos. Portanto, definir o escopo para a governança SOA pode ser um 
desafio. 

A governança SOA deve ser uma extensão dos modelos de governança de 
TI e de arquitetura empresarial existentes em uma organização, com o objeti¬ 
vo de fornecer novos ativos e políticas SOA. 

Estender um modelo existente de governança reduz o risco de criar silos 
de governança descoordenados, o que potencializaria a duplicação de áreas de 
coberturas existentes no modelo de governança da organização. 


13 . 2.2 Modelos de referência relacionados 

Para endereçar todos os desafios e as metas citados na seção anterior, faz-se 
necessário um modelo de governança SOA abrangente e compatível com o 
ambiente da organização e que seja implementado de forma iterativa e incre¬ 
mental. Um modelo abrangente de governança SOA deve cobrir os seguintes 
aspectos: 

□ Processos : incluindo processos de governança e processos governados. 

□ Estruturas organizacionais : incluindo pessoas em seus papéis e respon¬ 
sabilidades. 

□ Tecnologia : incluindo ferramentas e infraestrutura. 

Sem a adoção de um modelo robusto de governança, a implementação 
SOA não oferecerá todos os benefícios esperados. 
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13.2.2.1 Um jramework para governança SOA 

O objetivo de um framework de governança SOA é permitir que as organi¬ 
zações definam e implantem seus próprios modelos de governança, focando e 
customizando as necessidades da organização. 

Um jramework deve definir uma abordagem incremental de implantação 
da governança SOA, evitando assim a abordagem big bang de implantação 
(não recomendada neste caso, por requerer uma forte mudança de cultura 
de uma organização). Portanto, as organizações podem continuar a atender 
a suas demandas do dia a dia, enquanto movimentam-se em direção aos seus 
objetivos SOA de longo prazo. 

Não existe um modelo único para uma boa governança SOA, devido às 
variantes dentro de uma organização. Podemos considerar como exemplos 
dessas variantes a existência de governança, o nível de maturidade SOA, o ta¬ 
manho da organização etc. Um modelo de governança SOA apropriado para 
uma organização deve definir: 

□ Quais decisões precisam ser tomadas na organização para ter uma 
governança SOA efetiva. 

□ Quem deve tomar estas decisões sobre governança SOA na organização. 

□ Como as decisões de governança SOA serão tomadas e monitoradas 
em uma organização. 

□ Qual estrutura organizacional, processos e ferramentas devem ser im¬ 
plantados na organização. 

□ Quais métricas são exigidas para garantir que a implementação SOA 
da organização satisfaça os seus objetivos estratégicos. 

As organizações devem avaliar de forma imparcial seu regime atual de go¬ 
vernança, bem como as metas de práticas de governança. A partir desse ponto, 
pode ser criado um roteiro viável para entrega da governança. 

Normalmente, um jramework de governança SOA consiste em um modelo 
de referência de governança SOA, que é utilizado como “pontapé” inicial, e 
um método de vitalidade da governança SOA, que consiste na definição e me¬ 
lhoria contínua de processos (utilizando como princípio um ciclo “Planejar, 
Definir, Implementar, Monitorar”, como uma variante do ciclo “PDCA”), 
com objetivo de definir um regime de governança SOA customizado e com 
ênfase nas necessidades da organização. 
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13.2.2.2 Um modelo de referência para governança SOA 

Este é um modelo genérico que estabelece uma base de entendimento. É 
utilizado para acelerar o processo de tailoring do regime de governança SOA 
de uma organização. 

Os aspectos do modelo de referência de governança SOA devem ser revisa¬ 
dos e considerados para customização do ambiente da organização. Os exem¬ 
plos fornecidos pelo modelo de referência de governança SOA são destinados 
a servir como ponto de partida para discussões, que podem ser selecionados 
ou estendidos. 

Um modelo de referência de governança SOA é constituído de: 

□ Princípios orientadores de governança SOA. 

□ Processos para governança SOA (processos que governam). 

□ Processos da governança SOA (processos que devem ser governados). 

□ Artefatos do processo de governança SOA. 

□ Papéis e responsabilidades de governança SOA. 

□ Tecnologia de governança SOA. 


13.2.2.3 Princípios orientadores da governança SOA 

Os princípios orientadores da governança SOA auxiliam na priorização 
e tomada de decisão para concepção, implantação e execução do regime de 
governança SOA, incluindo aspectos relacionados a pessoas/papéis, processos 
e tecnologia. Adicionalmente, esses princípios devem ser utilizados para auxi¬ 
liar uma organização a alcançar o compromisso dos stakeholders no regime de 
governança SOA. 

A Tabela 13.1, a seguir, apresenta os princípios orientadores da gover¬ 
nança SOA. A maturidade em governança e SOA da organização influen¬ 
ciará como tais princípios serão selecionados e, estritamente, como serão 
aplicados. Normalmente, um subconjunto desses princípios será seleciona¬ 
do e modificado. 
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Princípio 

Descrição 

Fundamentação 

Governança SOA deve 
promover o alinhamento 
entre o negócio e a TI 

0 programa de governança SOA 
deve suportar diretrizes de negócio 
e TI. Os stakeholders de negócio e 

TI devem participar da governança 
e da execução do programa SOA da 
organização. 

SOA destina-se à condução ágil e 
flexível para o negócio e TI. Falhar no 
fomento da governança reduzirá os 
benefícios da abordagem orientada a 
serviços. 

Em conformidade com a 
governança da organização 

As atividades de governança SOA 
devem estar em conformidade 
com os princípios e padrões da 
governança de negócio, TI e 
arquitetura empresarial (EA). 

Os procedimentos de governança da 
organização são parte da estratégia da 
organização e também devem ser uma 
parte da governança SOA. 

Uma arquitetura de 
referência SOA é exigida 

Uma arquitetura de referência 

SOA fornece um conjunto de 
padrões arquitetônicos, normas e 
melhores práticas para o uso no 
desenvolvimento de soluções SOA. 

0 uso de artefatos de arquiteturais 
aprovados pela Arquitetura de Referência 
SOA reduzirá o risco e diminuirá os 
custos do projeto pela redução do 
número e da complexidade de atividades 
de concepção e design no projeto. 
Arquiteturas de referência da organização 
podem ser baseadas em arquiteturas de 
referência padrão SOA ou arquiteturas de 
referência da indústria. 

Todas as arquiteturas de solução 

SOA devem ser criadas com base 
na arquitetura de referência SOA da 
organização. 

Contratos de provedores e 
consumidores 

Contratos devem existir entre 
provedores e consumidores de 
serviço. 

Contratos podem ser ditados por 
apenas um lado. 

Garantir a entrega correta do serviço. 

Metadado de serviço 

Para habilitar decisões e 
descrições relacionadas aos 
serviços e seus respectivos 
contratos a serem armazenadas 
em uma localização conhecida, 
incluindo relacionamentos 
entre serviços e seus artefatos 
associados. 

Compreensão do propósito do serviço. 
Análise de impacto na continuidade de 
negócio. 

Análise de causa-raiz. 

Stakeholders da governança 
identificados 

Os stakeholders devem ser 
identificados e aceitar a 
responsabilidade pelos processos de 
governança. 

Garantir a execução adequada da 
governança. 

Comunicar o valor da governança SOA 
(benefícios). 

Comunicar os processos e 
procedimentos apropriados da 
governança SOA. 
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Princípio 

Descrição 

Fundamentação 

Processos sob medida de 
governança SOA 

Os processos de governança SOA 
devem ser adaptados baseando-se 
nos objetivos, no escopo do projeto 
e no risco. 

Somente faça a governança o quanto for 
necessário. 

Racionalize os custos da governança 
SOA. 

Automatizar processos de 
governança SOA 

Deve ser possível automatizar os 
processos da governança SOA. 

Facilita a aplicação coerente e 
eficiente. 

Reduz o pessoal necessário para 
executar o trabalho. 

Reduz o treinamento de pessoas. 

Propicia processos de governança mais 
confiáveis e rastreáveis. 

Implementar modelo de 
financiamento 

Todos os serviços e soluções devem 
estar cobertos por um modelo de 
financiamento. 

Garantir que a organização esteja 
disposta a desenvolver e suportar 
serviços necessários por longo prazo, 
sobretudo se os serviços puderem 
ser utilizados através de modelos de 
financiamento da organização. 

Serviços desenvolvidos em uma 
base ad hoc não podem ser 
oficialmente suportados por defeitos, 
conformidade, aprimoramento e 
desempenho. 

Reutilizar serviço 

Serviços existentes devem ser 
sempre considerados primeiro ao 
criar novas soluções SOA. 

Reutilização antes da compra/ 
construção diminui custo e 
complexidade. 

Descrever serviço 

Descrições devem ser adequadas 
para suportar a tomada de decisão 
de um potencial consumidor de 
utilizar o serviço. 

Garantir que os potenciais consumidores 
tenham as informações adequadas para 
decidir se o serviço é apropriado para 
suas necessidades. A descrição pode 
incluir: 

• Metadados do serviço. 

• Políticas. 

• Contratos. 

• Modelo de financiamento (atual e 
projetado). 

• Ajuda com objetivo de suportar a 
reutilização de serviços existentes. 

Coletar serviço 

Soluções devem ser revisadas para 
coleta de serviços reutilizáveis. 

Soluções existentes são as melhores 
fontes para reutilização de serviços com 
o mínimo de desenvolvimento e custo de 
manutenção. 

Novas soluções devem considerar 
a coleta de serviços durante o 
estágio inicial de desenvolvimento e 
continuamente. 
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Princípio 

Descrição 

Fundamentação 

Monitoramento de serviço 

Adesões aos contratos de serviço 
devem ser monitoradas. 

Métricas devem ser coletadas e 
disponibilizadas. 

Garantir a entrega correta do serviço. 
Detectar violações ao contrato de 
serviço. 

Alimentar o serviço e a solução SOA. 
Suportar consumidores na escolha de 
um serviço com métricas apropriadas. 

Execução de política do 
serviço 

Politicas relacionadas a um serviço 
em tempo de projeto e de execução 
( run-time ) devem ser cumpridas. 

Garantir serviços de alta qualidade. 
Garantir que as condições para 
alcançar as metas estabelecidas sejam 
definidas. 

Segurança de serviço 

Contratos e descrições dos 
serviços devem ser revisados de 
acordo com conformidade dos 
requisitos de segurança de uma 
organização. 

Garantir níveis corretos de segurança e 
de risco. 

Atenderá arquitetura 
empresarial 

As soluções e os serviços SOA 
devem estar alinhados à arquitetura 
empresarial de uma organização (se 
existir). 

Garantir que a solução SOA e o serviço 
SOA atendam aos objetivos de longo 
prazo de uma organização. 


Tabela 13.1 - Princípios de governança SOA 
Adaptado de The Open Group (2009b) 


As organizações podem criar seus próprios princípios de SOA e de gover¬ 
nança SOA, de forma que estejam mais alinhados às suas necessidades. 


13.2.2.4 Os processos da governança SOA 

Os princípios orientadores da governança SOA auxiliam na priorizaçáo e 
na tomada de decisão para concepção, implantação e execução do regime de 
governança SOA, incluindo aspectos relacionados a pessoas/papéis, processos 
e tecnologia. Adicionalmente, os princípios orientadores de governança SOA 
devem ser utilizados para auxiliar uma organização a alcançar o compromisso 
dos stakebolders no regime de governança SOA. 

Os processos da governança SOA realizam as intenções de governança da 
organização, ou seja, são os processos que o modelo de governança utiliza 
para governar qualquer processo em particular. Os processos de governança 
(governados) são aqueles que estão sendo controlados, monitorados e mensu¬ 
rados (exemplo: testes, desenho da solução, implantação etc.). 
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De acordo com The Open Group (2009), o modelo de referência de gover¬ 
nança SOA define três processos: Compliance , Dispensation e Comunicação . 
Cada um desses processos deve ser executado continuamente. 

□ Compliance-. 

A Seu objetivo é definir um método para garantir que as políticas, 
diretrizes e normas SOA sejam respeitadas. O processo de com¬ 
pliance fornece um mecanismo para revisar e aprovar/rejeitar de 
acordo com os critérios estabelecidos no jramework de governan¬ 
ça (exemplo: princípios, normas, papéis e responsabilidades etc.). 
Normalmente este processo é um complemento no processo exis¬ 
tente de revisão da qualidade. 

A O processo de compliance é um processo contínuo. Portanto, se 
uma revisão não é aprovada temos uma exceção no processo de 
compliance. A causa dessa exceção deve ser ajustada ou realinhada 
com o objetivo de atender aos requisitos de compliance. 

□ Dispensation: 

A O processo de dispensation fornece um caminho alternativo atra¬ 
vés da concessão de permissão de continuidade para os pontos de 
exceção verificados no processo de compliance. As concessões de 
execução em um caminho alternativo ocorrem por um período 
de tempo predeterminado para um conjunto de serviços identifi¬ 
cados, e critérios operacionais devem ser cumpridos durante esse 
período. 

A O processo de dispensation é utilizado como um mecanismo para 
garantir que os níveis de serviço e níveis operacionais sejam satis¬ 
feitos, enquanto fornecem um nível de flexibilidade em sua im¬ 
plementação e tempo. 

□ Comunicação: 

A O processo de comunicação suporta o regime de governança 
SOA, políticas, diretrizes e normas SOA por toda a organiza¬ 
ção. O processo também assegura que os processos da gover¬ 
nança são reconhecidos dentro dos processos de governança 
(governados). 

A A seguir, estão relacionadas informações que devem ser comuni¬ 
cadas no contexto da governança SOA: 
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° Valor de SOA e da Governança SOA. 

° Políticas, normas e diretrizes. 

° Processos de compliance. 

° Processo de dispensation. 

° Organização, papéis e responsabilidades. 

° Tecnologia sendo governada e utilizada pelos processos da 
governança. 

° Processos de governança (governados) e pontos de controle. 


13.2.2.5 Processos governados SOA 

A governança SOA inicia com o alinhamento entre as governanças de ne¬ 
gócio, a TI e a arquitetura empresarial (EA). Isso começa com o alinhamento 
da governança organizacional e termina com a execução contínua e em con¬ 
formidade durante a operação. 

Um processo de governança (governado) SOA inclui planejamento, con¬ 
cepção/desenho e aspectos operacionais de SOA, como sugerido no modelo 
da Figura 13.4: 



1 

Solução I 

1 

Serviço 

Planejamento 

Gerenciamento 
do Portfólio de 
Solução 

1 

1 

1 

■ 

Gerenciamento 
do Portfólio de 
Serviço 



_ 1_ 

1 


Projeto e 
Operação 

Ciclo de Vida da 
Solução 

1 

1 

1 

1 

Cicio de Vida do 
Serviço 


1 



Figura 13.4 - Processos governados de SOA 
Adaptado de The Open Group (2009b) 


No nível de projeto, o processo de Gerenciamento do Portfólio de So¬ 
luções enfatiza o planejamento e a priorização de soluções individuais de 
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SOA. Essas soluções individuais podem consumir serviços existentes, bem 
como definir novos serviços. Seguindo as orientações do processo de Geren¬ 
ciamento do Portfólio de Serviços, essas soluções podem consumir serviços 
reutilizáveis pelo processo de Ciclo de Vida do Serviço e/ou definir novos 
serviços para Gerenciamento do Portfólio de Serviço. Portanto, os novos 
serviços são priorizados pelo Gerenciamento do Portfólio de Serviço para 
o processo de Ciclo de Vida do Serviço, que gerencia o consumo pela so¬ 
lução individual SOA. A Tabela 13.2 mostra esses processos governados, 
suas atividades e as questões que devem ser consideradas como chaves para 
a governança SOA: 


Processos Governados de SOA 

Processo 

Questões-chave para SOA 

Atividades do 

Processo 

Gerenciamento do Portfólio de Serviços: 

É o processo SOA para garantir que uma 
organização possua o conjunto de serviços 
adequados às suas necessidades. 

Este processo fornece o maior valor agregado 
quando desempenhado em âmbito corporativo. 
Ao estabelecer estratégias de planejamento 
de serviços de acordo com negócio, TI 
e princípios e metas da governança da 
arquitetura empresarial (EA), o processo 
de Gerenciamento do Portfólio de Serviços 
possui a responsabilidade de planejar, atribuir 
a implementação para projetos específicos e 
implantar os serviços no tempo certo. 

• Planejamento para identificar 
os serviços adequados com 
o objetivo de criar agilidade 
nos negócios e maximizar a 
reutilização. 

• Modelos de financiamento que 
suportam agilidade do negócio e 
reutilização por toda organização. 

• Resolver questões sobre a 
propriedade de serviços por toda 
a organização. 

• Planejamento do 
portfólio de serviços. 

• Propriedade de 
serviço. 

• Gerenciamento de 
mudança de serviço. 

• Identificação de 
serviço. 

• Financiamento de 
serviço. 

Gerenciamento do Ciclo de Vida de Serviço: 

É a extensão do ciclo de vida de 
desenvolvimento de software da organização 
(SDLC), incluindo ou colocando ênfase em 
atividades necessárias para o ciclo de vida 
de serviço. 0 processo de gerenciamento do 
ciclo de vida de serviço abrange conceituação/ 
projeto, desenvolvimento, implantação, 
gerenciamento e descomissionamento do 
serviço. 

• Adaptar o ciclo de vida de 
desenvolvimento de software 
atual para o ciclo de vida de 
desenvolvimento de serviços. 

• Estabelecer e aprovar os 
contratos de serviços (por 
exemplo: processos de negócio 
terão a capacidade necessária). 

• Publicação de serviços, a fim de 
habilitar o reuso. 

• Gerenciar múltiplas versões de 
um serviço. 

• Detectar o uso inadequado de 
serviço. 

• Atender SLAs e arquiteturas, a fim 
de habilitar o próprio SLA. 

• Gerenciar políticas. 

• Definição de serviço. 

• Planejamento da 
realização de serviço. 

• Modelagem de 
serviço. 

• Implementação, 
montagem ou 
aquisição de serviço. 

• Teste de serviço. 

• Implantação de 
serviço. 

• Monitoração e 
gerenciamento de 
serviço. 

• Suporte ao serviço. 
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Processos Governados de SOA 

Processo 

Questões-chave para SOA 

Atividades do 

Processo 

Ciclo de Vida da Solução SOA: 

0 Ciclo de Vida da Solução SOA suporta a 
conceituação/projeto, o desenvolvimento, a 
implantação, o gerenciamento, a mudança e o 
descomissionamento de soluções SOA. 

A maior parte da solução de desenvolvimento 
SOA é governada nos processos de Ciclo de 
Vida da Solução SOA. 

• Garantir que os processos de 
negócio para orquestrações do 
processo SOA incluam regras 
de negócio, gerenciamento do 
processo de negócio e tecnologias 
relacionadas. 

• Garantir que as interfaces do 
gerenciamento do portfólio de 
serviço incluam a identificação 
de serviço e contratos de serviço 
utilizados por fornecedores e 
consumidores. 

• Habilitar a montagem de 
serviço para construir serviços e 
aplicações combinadas. 

• Garantir que a certificação de 
serviço durante a implantação 
inclua a validação dos contratos de 
serviços, bem como os requisitos 
funcionais e não funcionais. 

• Habilitar o gerenciamento 
operacional de serviço, que inclui 
a verificação, o monitoramento do 
serviço e o relatório do nível de 
serviço acordado (SLA). 

• Garantir o gerenciamento da 
mudança para os serviços SOA, 
incluindo a análise de impacto 
precisa dos serviços implantados. 

• Garantir a alocação apropriada de 
custos para o desenvolvimento e 
a execução de serviços. 

• Definição da solução. 

• Planejamento 
de realização de 
solução. 

• Planejamento 
e exceções na 
reutilização de 
serviço. 

• Modelagem da 
solução. 

• Implementação, 
montagem ou 
aquisição de solução. 

• Testes da solução. 

• Implantação de 
solução. 

• Monitoramente e 
gerenciamento da 
solução. 

• Suporte da solução. 

• Direitos/Uso SOA. 

Gerenciamento do Portfólio de Soluções: 

É o processo para garantir que a organização 
possua o conjunto de soluções SOA adequado 
às suas necessidades e capacidades de 
implementação e compreensão. 

Este processo identifica o escopo da solução 
e desenvolve planos para solução para reuso 
e desenvolvimento de novos serviços, com o 
objetivo de atender aos requisitos da solução. 

0 Gerenciamento do Portfólio de Soluções 

SOA é a extensão do Gerenciamento do 
portfólio de TI, incluindo ou enfatizando 
algumas atividades necessárias para gerenciar 
o portfólio de soluções SOA. 

• Garantir que SOA seja um padrão 
de solução válido para endereçar 
o problema de negócio. 

• Garantir que a análise de retorno 
sobre o investimento SOA seja 
executada. 

• Garantir que o financiamento da 
solução SOA esteja disponível. 

• Aculturar e treinar os stakeholders 
no portfólio de soluções SOA 

e em seus benefícios para o 
negócio. 

• Planejamento do 
portfólio de soluções. 

• Financiamento de 
solução SOA. 

• Viabilidade da 
solução SOA. 

• Gerenciamento de 
mudança da solução 
SOA. 


Tabela 13.2 - Processos governados de SOA 
Adaptado de The Open Group (2009b) 
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13.2.2.6 Método de vitalidade da governança SOA 

O método de vitalidade de governança SOA é um processo que começa 
com a adoção de um modelo de referência de governança SOA e segue por 
uma série de fases e atividades, a fim de customizá-lo de acordo com as va¬ 
riantes da organização. 

Portanto, as fases do método de vitalidade de governança SOA devem ser 
visualizadas como um ciclo de melhoria contínua, pelo qual o progresso é 
mensurado. Correções de curso e atualizações no regime de governança SOA 
são executadas quando necessárias. 


13 . 2.3 Aplicabilidade do conceito 

A aplicabilidade do conceito de governança SOA é sugerida por The Open 
Group (2009), através das seguintes fases do método de vitalidade da gover¬ 
nança SOA: 

□ Fase de planejamento : durante esta fase, as necessidades e prioridades 
do negócio são documentadas, juntamente com o papel da organi¬ 
zação de atingir tais necessidades. A situação e a maturidade do atual 
modelo de governança da organização são avaliadas e as lacunas são 
identificadas. A partir dessa análise, a visão, a estratégia e o escopo da 
governança SOA são documentados. Um roteiro possivelmente será 
criado, com o objetivo de estabelecer iterações futuras do método de 
vitalidade da governança SOA. Nesta fase, são executadas as seguintes 
atividades: 

A Entender a estrutura atual de governança. 

A Avaliar maturidade SOA. 

A Desenvolver visão e estratégia da governança SOA. 

A Desenvolver escopo da governança SOA. 

A Desenvolver princípios da governança SOA. 

A Desenvolver roteiro da governança SOA. 

□ Fase de definição: o resultado da fase de planejamento é comparado 
com um modelo de referência de governança SOA, a fim de estabe¬ 
lecer um alvo para a governança SOA da organização, no tocante a 
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arquiteturas, processos e tecnologias. A lacuna entre a governança 
SOA atual e o modelo alvo é analisada, com o objetivo de criar um 
conjunto de roteiros de transição. Nesta fase, são executadas as se¬ 
guintes atividades: 

A Entender a estrutura atual de governança. 

A Definir processos governados SOA. 

A Definir processos da governança SOA. 

A Coletar normas e orientações para SOA. 

A Definir papéis e responsabilidades, além da organização da gover¬ 
nança SOA. 

A Definir informações para os artefatos da governança SOA. 

A Definir o ambiente da governança SOA. 

A Estabelecer planos de transição. 

° Plano de transição organizacional. 

° Plano de transição de processos. 

° Plano de transição de tecnologia. 

□ Fase de execução: a fase de execução é responsável por realizar a so¬ 
lução de governança determinada nas fases de planejamento e defi¬ 
nição. Nesta fase são executados os planos de transição, incluindo a 
implantação de processos, aspectos organizacionais e de tecnologia 
relativos ao modelo de governança SOA. 

□ Fase de monitoramento: esta fase é responsável por monitorar os 
processos da governança, bem como os processos governados, com 
o objetivo de identificar se o regime de governança SOA precisa ou 
não ser ajustado. Caso haja necessidade de realizar ajustes, uma nova 
iteração do método de vitalidade da governança SOA é iniciada. Nes¬ 
ta fase, são executadas as seguintes atividades: 

A Monitorar e avaliar os processos de governança SOA. 

A Monitorar e avaliar os processos governados SOA. 

A Monitorar mudanças externas. 

A Monitorar e avaliar o desenvolvimento de orientações SOA. 

Outra abordagem, sugerida por Marks (2008), também recomenda um 
modelo de ciclo de vida para adoção de SOA, conforme descrito a seguir e 
ilustrado na Figura 13.5: 
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□ SOA Inception: pilotos iniciais de SOA e Web Services e provas de 
conceito acontecem nesta fase. O principal objetivo é nivelar o co¬ 
nhecimento do time nos conceitos fundamentais. 

□ Planejamento e Estratégia SOA: esta fase procura alinhar todas as 
atividades SOA sob uma estratégia coerente e um roteiro de execu¬ 
ção, com patrocínio e liderança de um executivo corporativo. 

□ Desenvolvimento do Modelo de Governança SOA: esta fase en¬ 
volve o desenvolvimento e a implementação de um modelo de go¬ 
vernança SOA já alinhado e suporta a realização dos objetivos e das 
metas SOA da organização. Para que se obtenha um modelo efetivo 
de governança SOA, é de fundamental importância executar a fase 
anterior, ou seja, a fase de Planejamento e Estratégia SOA. 

□ SOA Ramp and Governance Rantp: esta fase está focada na prepara¬ 
ção formal e programática da execução de uma iniciativa SOA dentro 
da organização. As principais atividades relacionadas a esta fase são: 
treinamento do time envolvido, desenvolvimento de artefatos de ar¬ 
quitetura de referência, padrões de projeto e interoperabilidade de 
serviço, especificação e aquisição de desenvolvimento SOA, testes, 
definição do ciclo de vida de desenvolvimento SOA e implementação 
do processo de governança SOA. 

□ Implementação de Referência SOA: esta fase é um importante marco. 
A partir do momento em que a organização preparou as atividades ramp. 
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pode-se iniciar a implementação do primeiro projeto “verdadeiramente” 
SOA. O projeto deve ser selecionado, planejado e executado cuidadosa¬ 
mente, de forma que represente o estado final de SOA da organização, 
ou seja, a implementação final de SOA da organização pelas perspecti¬ 
vas de negócio, processo, governança e tecnologia. Essa implementação 
de referência servirá como núcleo em torno do qual o time irá iterar e 
expandir capacidades, processos, governança e implementações SOA. 

□ Programa SOA: é na fase de programa SOA que a organização inicia a 
execução formal de projetos SOA, de acordo com sua própria definição 
de estratégia SOA e seu modelo de governança SOA, utilizando sua 
implementação de referência SOA como plataforma para execução. 


OBS.: é muito comum que algumas empresas tentem realizar a transi¬ 
ção da fase de SOA Inception para a fase de Programa SOA diretamente, 
ignorando as fases de Planejamento e Estratégia SOA, Desenvolvimento 
do Modelo de Governança SOA e SOA Ramp and Governance Ramp. Essas 
empresas geralmente obtêm implementações bottom-up limitadas de SOA, 
cujo valor de negócio, por consequência, é também limitado. 


□ Assimilação e Aceleração SOA: esta é a fase onde a organização apro¬ 
veita a implementação de referência SOA para adicionar novas capaci¬ 
dades e processos, expandir o consumo do serviço, desenvolver novos 
serviços e acelerar a adoção de SOA através dos seus clientes de TI e 
negócio. Geralmente, durante esta fase, a SOA torna-se internaliza¬ 
da pela organização como o principal meio pelo qual capacidades de 
negócio serão habilitadas por TI e também pelo qual a TI irá operar. 

□ Execução Programada de SOA: nesta fase, SOA torna-se um mode¬ 
lo contínuo e padronizado para a entrega de soluções e capacidades 
de negócio via serviços. Estar nesta fase significa que uma organização 
está provendo benefícios SOA através de entregas velozes de serviços, 
onde o reuso de serviços é acelerado e os benefícios desejados pela 
organização podem ser mensurados e demonstrados. 

□ Estado de Equilíbrio SOA: nesta fase, SOA terá se tornado o mode¬ 
lo fundamental pelo qual os serviços de TI são entregues, evidencian¬ 
do que o modelo de SOA está claro e assumido para negócio e TI. 
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13 . 2.4 Certificações relacionadas 

Os profissionais de tecnologia da informação podem encontrar diversos 
programas de certificação relacionados à Arquitetura Orientada a Serviços 
(SOA), oferecidos por instituições renomadas como o SEI ( Software Engi- 
neering Instituté), o SOA Systems Inc. e também por fabricantes de softwares 
como IBM e Oracle. 

A SOA Systems Inc. desenvolveu um currículo de certificações com base na 
perspectiva vendor-neutral (perspectiva imparcial de fabricantes de softwares), 
denominado SOACP (SOA Certified Professional). O programa de certifica¬ 
ções é supervisionado pelo reconhecido SOA Education Committee. O referi¬ 
do currículo oferece as seguintes certificações: 

□ Certified SOA Professional. 

□ Certified SOA Consultant. 

□ Certified SOA Analyst. 

□ Certified SOA Arcbitect. 

□ Certified SOA Security Specialist. 

□ Certified SOA Java Developer. 

□ Certified SOA .NETDeveloper. 

□ Certified SOA Governance Specialist. 

□ Certified SOA Quality Assurance Specialist. 

□ Certified SOA Irainer. 

Para informações mais detalhadas sobre o currículo SOACP, visite o se¬ 
guinte endereço na Internet:_http://www.soaschool.com 

O renomado Instituto de Engenharia de Software SEI oferece dois currí¬ 
culos distintos, com o objetivo de credenciar o profissional de tecnologia da 
informação. O currículo SOA Instructor oferece duas certificações: 

□ Service-Oriented Architecture: Best Practices for Successful Adoption 
Instructor. 

□ Service-Oriented Architecture: Legacy Systems Migration Instructor. 

Outro programa de certificação oferecido pelo SEI é o SOA SMART Team 
Lead , o qual credencia o profissional de TI como especialista em SOA, focan¬ 
do em migração, adoção e técnicas de reutilização do framework. 
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Ambas as certificações fornecidas pelo SEI sáo válidas por um perío¬ 
do de dois anos. Após esse prazo, o profissional certificado deve ingres¬ 
sar no programa de renovação, onde cada currículo possui requerimentos 
específicos. 

Para informações mais detalhadas sobre as certificações fornecidas pelo SEI, 
visite o seguinte endereço na Internet:_http://www.sei.cmu.edu/certification/soa 


13.3 Governança de Dados 


NOTA: esta seção é uma contribuição da consultora Maritza Maura de 
Carvalho Francisco, MSc., especialista em projetos e iniciativas utilizando 
princípios de gestão e governança de dados. 


O modelo de governança corporativa apresenta aspectos essenciais para a 
prática de boa governança, dentre os quais podem ser citadas a segurança e a 
qualidade dos dados. 

A capacidade das organizações em proteger seus dados, revesti-los de qua¬ 
lidade e produzir informações confiáveis, precisas, acessíveis e disponíveis em 
momento oportuno é um dos principais fatores que determinam o valor das 
empresas modernas. 

Um estudo realizado pelo Conselho de Governança de Dados da IBM 
identificou importantes desafios na área de gerenciamento de informações. 
Conforme a IBM (2006), dentre as principais tendências identificadas por 
este estudo podem ser citadas: 

□ A governança de dados se tornará um requisito regulatório, e as em¬ 
presas terão que demonstrar suas práticas de governança aos órgãos 
fiscais como parte de auditorias regulares. 

□ O valor dos dados será tratado como um ativo no balanço e relatado 
pelo CFO, ao mesmo tempo em que a qualidade dessas informações 
se tornará uma importante métrica para a TI. 

□ Mudança no papel e posicionamento do CIO, que passará a ser res¬ 
ponsável por relatar riscos relativos à qualidade de dados ao Conselho 
Diretor e terá autoridade para gerenciar o uso da informação. 
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Nesse cenário, da mesma forma que é essencial que haja alinhamento e 
transparência entre a Governança Corporativa e a Governança de TI, é in¬ 
dispensável que haja integração entre esta última e a Governança de Dados. 
É sobre esse tema que os próximos tópicos discorrem. 


13 . 3.1 Princípios e conceitos gerais 

Qual é a diferença entre Governança de Dados e Governança de TI? A 
Governança de TI concentra seus esforços em solucionar questões relativas ao 
gerenciamento do portfólio de serviços, projetos e infraestrutura de TI. Já as 
questões específicas do gerenciamento de dados exigem um grupo multifun¬ 
cional que tenha o conhecimento necessário para a tomada de decisões rela¬ 
cionadas à gestáo de dados. Isso náo quer dizer que a Governança de TI não 
aborde as questões que envolvam dados; porém, essa abordagem é genérica, 
náo tratando das especificidades do universo de dados. 

A Governança de Dados exige um conhecimento específico e a participa¬ 
ção de especialistas que compreendam os dados e as técnicas para planejá-los, 
modelá-los, criá-los, mantê-los, integrá-los e distribuí-los. 

Governança de Dados, segundo o Data Governance Institute (DGI) - ver 
Thomas (2009) - é um sistema de tomada de decisáo e responsabilidades 
para os processos relacionados aos dados, executado de acordo com políticas, 
normas e restrições. 

O foco de atuaçáo da Governança de Dados pode variar de organização 
para organização. Alguns programas de governança centram-se em privacida¬ 
de, compliance e segurança de informação; outros se concentram em aspectos 
da arquitetura e integração de dados que envolvem critérios de qualidade de 
dados. Ainda segundo o DGI, é imprescindível que as organizações definam 
suas necessidades de gestáo de dados e a partir daí delimitem o escopo de 
atuaçáo da Governança de Dados. 

Independentemente do foco definido pela organização, os objetivos listados a 
seguir sáo considerados comuns a qualquer programa de Governança de Dados: 

□ Permitir uma melhor tomada de decisáo. 

□ Reduzir o atrito operacional. 

□ Proteger as necessidades das partes interessadas (stakeholders). 

□ Institucionalizar uma gerência comum no tratamento de problemas 
de dados. 
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□ Construir padrões, processos e metodologias que possam ser dissemi¬ 
nadas pela organização. 

□ Reduzir custos e aumentar a eficácia através da coordenação de esfor¬ 
ços conjuntos. 

□ Garantir a transparência dos processos. 

De maneira genérica, a Governança de Dados, segundo o DGI, possui seis 
áreas-foco: 

□ Políticas, Normas, Estratégia. 

□ Qualidade dos dados. 

□ Privacidade/ Compliancel Security. 

□ Arquitetura/Integração. 

□ Data Warehouse (DW) e Business Intelligence (BI). 

□ Alinhamento entre a Governança de Dados e as estratégias de TI e 
negócio. 

Segundo o Data Management International - ver DAMA (2009) -, Gover¬ 
nança de Dados é uma disciplina que deve tratar do planejamento, da supervi¬ 
são e do controle sobre o gerenciamento de dados e o seu respectivo uso. 

Ainda de acordo com o DAMA DMBOK I a edição, a Governança de 
Dados é o exercício da autoridade, do controle e da tomada de decisão com¬ 
partilhada sobre a gestão dos ativos de dados e divide-se em dois grupos de 
atividades, conforme a Figura 13.6. 



Figura 13.6 - Atividades de Governança de Dados 
Adaptado de DAMA (2009) 
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O planejamento do gerenciamento de dados contempla: 

□ Planejamento e gestão de dados. 

□ Identificação de necessidades estratégicas de dados. 

□ Desenvolvimento e manutenção da estratégia de gerenciamento de 
dados. 

□ Estruturação e implementação da função de gerenciamento de da¬ 
dos, bem como a orientação dos profissionais responsáveis por esta 
função. 

□ Identificação e nomeação dos profissionais que exercerão os papéis 
inseridos no contexto de dados, tais como administradores de dados, 
administradores de metadados, administradores de banco de dados, 
dentre outros. 

□ Estabelecimento da função de Gestor da Informação e orientação do 
trabalho relativo a esta função. 

□ Desenvolvimento, revisão e aprovação das políticas de dados, normas 
e procedimentos, revisão e aprovação da arquitetura de dados. 

□ Estimativa do valor dos ativos de dados e os custos associados ao seu 
gerenciamento. 

No controle e na supervisão do gerenciamento de dados estão inseridos: 

□ Supervisão das áreas e dos profissionais relacionados ao Gerencia¬ 
mento de Dados. 

□ Coordenação das atividades de governança. 

□ Gerenciamento e resolução dos problemas de dados. 

□ Monitoramento e garantia da conformidade regulatória, contem¬ 
plando políticas, normas e arquitetura de dados. 

□ Supervisão e gestão de projetos e serviços de dados. 

□ Promoção do valor dos ativos de dados. 

Independentemente do conceito adotado pela organização para a imple¬ 
mentação da Governança de Dados, é necessária a utilização de metodologias 
que direcionem as ações para que esta implementação seja bem-sucedida. A 
seguir são apresentadas três referências cuja utilização é possível neste contex¬ 
to: CobiT, DAMA DMBOK e DGI Framework. 
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13 . 3.2 Modelos de referência relacionados 

13.3.2.1 CobiT 

O CobiT é um framework que promove um conjunto de padrões e boas 
práticas para o gerenciamento e o uso corporativo e transparente da TI, sendo 
considerado um padrão para o gerenciamento e a governança corporativa de 
TI, alinhado às estratégias de negócio. 

Duas das práticas de gerenciamento do CobiT 5 endereçam as questões 
relacionadas à informação (algumas de suas atividades estão evidenciadas): 

□ APO01.06 - Definir a propriedade de informações (dados) e sis¬ 
temas 121 (do processo APOOl - Gerenciar o framework de gestão 
de TI): 

A Definir e manter responsabilidades pela propriedade de infor¬ 
mações (dados) e sistemas de informação. Assegurar que os pro¬ 
prietários tomem decisões sobre a classificação de informações e 
sistemas e a sua proteção com base nesta classificação. Envolve 
também atividades de definir e implementar procedimentos que 
garantam a integridade e a consistência de todos os dados arma¬ 
zenados em formato eletrônico, tais como bancos de dados, data 
warebouse e arquivos de dados. 

□ AP003.02 - Definir a arquitetura de referência 122 (do processo 
APO03 - Gerenciar a arquitetura corporativa): 

A Estabelecer e manter um modelo de informação corporativo (re¬ 
positório de arquitetura) consistente com a estratégia corporativa 
para habilitar o uso otimizado da informação para tomada de de¬ 
cisão. O modelo deverá facilitar a criação, o uso e o compartilha¬ 
mento de informações pela empresa. 

A Manter um dicionário corporativo que incorpore as regras de sin¬ 
taxe e semântica de dados. Este dicionário deve promover um 
entendimento comum e um esquema de classificação que inclua 


121 Esta prática de gerenciamento do CobiT 5 mapeia um objetivo de controle da versão 4.1 do CobiT 
(P02.4 - Gerenciamento da Integridade). 

122 Esta prática de gerenciamento do CobiT 5 mapeia três objetivos de controle da versão 4.1 do CobiT 
(P02.1 - Modelo Corporativo da Arquitetura da Informação, P02.2 - Dicionário de Dados Corporativo e 
Regras de Sintaxe de Dados e P02.3 - Esquema de Classificação de Dados). 
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detalhes sobre a propriedade dos dados, a definição dos níveis de 
segurança apropriados e requisitos de retenção e destruição de da¬ 
dos. Além disso, deve permitir o compartilhamento de elementos 
de dados entre aplicações e sistemas, o entendimento comum dos 
dados entre TI e negócios e impedir a criação e o uso de elemen¬ 
tos incompatíveis com a arquitetura definida. 

Além das práticas de gerenciamento, o CobiT possui uma publicação em 
sua família de produtos que consiste em um guia de referência para estruturar 
o pensamento acerca da informação e das questões relacionadas a governança 
e gerenciamento da informação: o CobiT 5: Enabling Information [ISACA 
(2013b)]. Nessa publicação, a informação é tratada como um ativo corporati¬ 
vo e/ou como um importante habilitador da governança e do gerenciamento. 

De acordo com ISACA (2013b), os objetivos da chamada “ governança da 
informação ” são: 

□ Assegurar a avaliação das necessidades, condições e opções das partes 
interessadas para determinar metas corporativas balanceadas e acor¬ 
dadas, a serem atingidas por meio da aquisição e do gerenciamento 
de recursos de informação. 

□ Assegurar o direcionamento das capacidades de gerenciamento da in¬ 
formação de forma priorizada e orientada à tomada de decisão. 

□ Assegurar o monitoramento do desempenho e da conformidade dos 
recursos de informação em relação às políticas, padrões, arquiteturas 
e procedimentos acordados. 

Já o gerenciamento da informação planeja, constrói, executa e monitora 
as práticas, projetos e capacidades que adquirem, controlam, entregam e me¬ 
lhoram o valor dos ativos de dados e informações, de forma alinhada com as 
diretrizes estabelecidas pela governança da informação. 

O CobiT sugere ainda um conjunto de métricas para avaliar a qualidade 
de itens de informação que suportam o atingimento das metas genéricas rela¬ 
cionadas àTI. Como exemplo, podem ser citadas: 

□ Tempo decorrido desde a última atualização do Plano Estratégico 
de TI (relacionado à meta ITG01 - “Alinhamento das estratégias de 
negócio e de TI”). 
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□ Quantidade de incidentes significativos relacionados à TI náo iden¬ 
tificados na avaliação de riscos (relacionado à meta ITG04 - “Riscos 
de negócio relacionados àTI gerenciados”). 

□ Percentual de políticas suportadas por padrões e práticas efetivas de 
trabalho (relacionado à meta ITG15 - “ Compliance da TI com polí¬ 
ticas internas”). 

□ Quantidade de horas de treinamento/aprendizado por pessoa (rela¬ 
cionado à meta ITG16 - “Pessoal de TI competente e motivado”). 

□ Grau de satisfação dos usuários de negócio com o treinamento e o 
manual do usuário (relacionado à meta ITG08 - “Uso adequado de 
aplicações, da informação e das soluções tecnológicas”). 

O CobiT oferece um guia para direcionar a empresa na institucionalização 
de uma governança de informações alinhada à Governança de TI. Entretanto, 
ele não descreve como os processos devem ser estruturados ou executados. 

13.3.2.2 DAMA-DMBOK 

Outro guia que pode orientar as empresas na tarefa de estabelecer um ge¬ 
renciamento estratégico de dados é o DAMA-DMBOK ( Data Management 
Body of Knowledge ). 

A DAMA, Data Management Association, é uma organização constituída 
por profissionais de gerenciamento de dados. A DAMA International , a Fun¬ 
dação DAMA, os capítulos locais e os membros individuais visam amadure¬ 
cer o gerenciamento de dados de diversas maneiras. O DMBOK é um “cor¬ 
po de conhecimento” sobre gerenciamento de dados que está em constante 
crescimento. Ele proporciona uma visão geral sobre gerenciamento de dados 
e define um padrão para a função de gerenciamento de dados, a terminologia 
e as melhores práticas, porém sem detalhar técnicas e métodos específicos. 

De acordo com a DAMA (2012), são dez as funções-chave para a função 
global de gestão de dados, conforme a Figura 13.7: 

□ Governança de Dados: planejamento, supervisão e controle sobre o 
uso e gestão de dados. 

□ Gestão da Arquitetura de Dados: definição do diagrama ( blueprint ) 
para a gestão dos ativos de dados. 
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□ Desenvolvimento de Dados: análise, desenho, implementação, tes¬ 
tes, implantação e manutenção de estruturas de dados. 

□ Gestão Operacional de Dados: presta suporte desde a aquisição de 
dados até a eliminação plena do dado. 

□ Gestão de Segurança de Dados: garantia de privacidade, confiden¬ 
cialidade e acesso apropriado a dados e informações. 

□ Gestão de Dados Mestres e de Referência: gerenciar as versões de 
dados originais e replicados em ambientes distribuídos. 

□ Gestão de Data Warehousing & Business Intelligence: permitir a 
disponibilização de informações para suporte à decisão e à imple¬ 
mentação de análises de dados sob várias dimensões de análise. 

□ Gestão de Conteúdo e Documentos: planejamento, implementação 
e controle de atividades para armazenar, proteger e acessar dados es¬ 
truturados ou não (fora de bases de dados). 

□ Gestão de Metadados: integração, controle e entrega de metadados 
sobre a arquitetura de dados e informações. 

□ Gestão da Qualidade de Dados: definição, monitoramento e me¬ 
lhoria da qualidade de dados. 



Figura 13.7 - Processos-chave do modelo DAMA-DMBOK 
Adaptado de DAMA (2012) 
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De maneira geral, o DMBOK apresenta um alto grau de detalhamento 
prático que não é encontrado no CobiT, enquanto este valoriza as práticas 
de governança de informação com o conceito de habilitador. Dessa forma, 
segundo a ISACA (2013b), pode-se afirmar que os dois modelos sáo comple¬ 
mentares entre si no âmbito da governança e do gerenciamento da informação. 


13.3.2.3 DGI Framework 

O Data Governance Institute criou um framework para auxiliar as empresas 
a empreenderem as iniciativas de Governança de Dados e a compreenderem 
questões vitais para o seu estabelecimento, tais como: 

□ A missáo da Governança de Dados. 

□ O trabalho que deverá ser realizado. 

□ Papéis funcionais envolvidos. 

□ Como esses papéis iráo interagir para gerar valor para a organização. 

□ Quando os processos serão executados. 

O framework proposto é flexível, podendo ser customizado de acordo com a 
necessidade da empresa. Possui dez componentes, conforme mostra a Figura 13.8: 



Figura 13.8 - Componentes do framework do DGI 
Adaptado de DGI (2006) 
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□ Missão: a Governança de Dados normalmente tem uma missão que 
se divide em três partes: 

A Definir e alinhar regras de maneira proativa. 

A Fornecer serviços de dados a todas as partes interessadas. 

A Reagir e resolver problemas decorrentes da não conformidade 
com as regras. 

□ Foco: objetivos, métricas e medidas de sucesso, estratégia de 
financiamento. 

□ Definição e regras de dados : este componente se refere às políticas 
relacionadas a dados, normas, requisitos de conformidade, regras 
de negócios. Dependendo de seu foco, o programa pode trabalhar 
para: 

A Criar novas regras e definições. 

A Reunir as regras e definições atuais. 

A Identificação de lacunas e sobreposições. 

A Alinhar e priorizar as regras e/ou definições conflitantes. 

□ Decisões : é necessário estabelecer o processo de tomada de decisão 
em relação aos dados, bem como quando as decisões devem ser to¬ 
madas e por quem. 

□ Papéis e responsabilidades : quem deve fazer o quê e quando, ou seja, 
estabelecimento de papéis e de suas respectivas responsabilidades. 

□ Controles : controles para os riscos do gerenciamento de dados, como 
a violação de dados sensíveis. 

□ Partes interessadas : 

A Envolvidos : definição de todos os profissionais envolvidos na Go¬ 
vernança de Dados. 

A Escritório de Governança de Dados : facilita e apoia as atividades 
de governança. Ele coleta as métricas e medidas de sucesso, elabora 
relatórios sobre os dados e os distribui para as partes interessadas. 
A Administradores e gestores de dados : conjunto de intervenientes 
de dados, que se reúnem para fazer decidir sobre as questões de 
dados. Eles podem definir políticas e especificar normas, ou esta¬ 
belecer recomendações que são aproveitadas por um nível mais 
alto, como, por exemplo, o comitê de governança. 
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□ Processos : atividades que contemplam: 

A Alinhamento de políticas, requisitos e controles. 

A Estabelecimento de processo de decisão. 

A Estabelecimento de papéis e responsabilidades. 

A Governança. 

A Gerenciamento de mudanças. 

A Definição de dados. 

A Resolução de problema. 

A Especificação de requisitos de qualidade dos dados. 
A Integração entre governança de dados e tecnologia. 
A Gerenciamento dos envolvidos. 

A Comunicações. 

A Medição e reporte do valor. 


13.3.2.4 Modelos de maturidade e de capacidade 

Os modelos de maturidade baseiam-se na premissa de que pessoas, or¬ 
ganizações, áreas funcionais e processos evoluem através de um processo de 
desenvolvimento que cresce em direção a uma maturidade mais avançada, 
atravessando um determinado número de estágios distintos. Esses modelos 
podem ser considerados metamodelos de processos e têm sido usados em 
várias áreas, tais como engenharia de software, engenharia de produção e ge¬ 
renciamento de projetos. 

Vários modelos de maturidade têm sido propostos ao longo do tempo, 
quer para a evolução geral das organizações, quer para a evolução particular de 
uma função, como, por exemplo, a Gestão de Sistemas de Informação. Esses 
modelos diferem, sobretudo, no número de estágios, variáveis de evolução e 
áreas de foco de atuação. Cada um desses modelos identifica certas caracterís¬ 
ticas que tipificam o alvo em diferentes estágios de maturidade. 

Entre os modelos de maturidade e de capacidade aplicáveis no contexto da 
Governança de Dados figuram o do CMMI, o do MR-MPS e o do CobiT 123 , 
já mencionados nos capítulos anteriores deste livro. 


123 No caso do CobiT 5, não há mais um modelo de maturidade, mas sim um modelo de capacidade de 
processos. 
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O foco da Governança de Dados determina o modelo de maturidade/capa- 
cidade a ser adotado. Para defini-lo podem ser utilizadas as práticas dos mode¬ 
los citados no tópico anterior: CobiT, DAMA DMBOK e DGI Framework. 

É muito salutar que se defina o modelo de maturidade/capacidade a ser 
utilizado em um processo de implementação de Governança de Dados, pois, 
desta forma, torna-se possível o estabelecimento da estratégica de evolução 
da Governança de Dados e a projeção antecipada dos resultados que se deseja 
alcançar e medir ao longo do tempo. 


13 . 3.3 Aplicabilidade do conceito 

A Governança de Dados direciona a estruturação de todo o sistema de 
gerenciamento de dados, possibilitando a estruturação de todos os processos 
relacionados à estruturação, ao compartilhamento, ao armazenamento, à uti¬ 
lização e à qualidade dos dados. Ela permite que efetivamente os dados sejam 
tratados como ativos de uma organização, sendo bem gerenciados e utilizados 
não somente nos processos decisórios como nos processos operacionais das 
empresas. Segundo Carvalho (2009), a capacidade de capturar, tratar, dispo¬ 
nibilizar e utilizar a informação em todos os seus processos de negócio traça 
o perfil competitivo das organizações. Nesse cenário, a Governança de Dados 
exerce o papel de ser um grande instrumento estratégico. 

Iniciativas de governança de dados nas empresas têm tomado impulso a 
partir de projetos de BI, Data Warehouse , Estruturação de Administração de 
Dados, Implementação de Metadados e Programas de Qualidade de Dados. 
Se observarmos bem, todos esses assuntos compõem o tema Governança de 
Dados. 

Independentemente do ponto de partida para a estruturação da Gover¬ 
nança de Dados, é importantíssimo escolher adequadamente o modelo de 
maturidade atrelado ao padrão de referência de implementação, que pode ser 
uma das opções citadas neste tópico. 


13 . 3.4 Certificações relacionadas 

No contexto de Governança de Dados, podem ser citadas duas certifica¬ 
ções de maior relevância: a CIMP ( Certified Information Management Profes- 
sionat) e a CDMP {Certified Data Management Professional). 
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A certificação CIMP propõe um programa que cobre cinco áreas: 

□ Fundamentos do Gerenciamento de Informação. 

□ Mestre em Gerenciamento de Dados. 

□ Qualidade de Dados. 

□ Modelagem de Dados e Gerenciamento de Metadados. 

□ Governança de Dados. 

Para obter a CIMP - Governança de Dados - o postulante deve se subme¬ 
ter ao programa CIMP e passar nos cinco exames online , conforme mostra a 
Tabela 13.3: 


Quadro de Exames CIMP 

Obrigatório 

Fundamentos de Governança de Dados (25 questões). 

Necessário passar em 
três dos cinco exames 
ao lado 

Criação e Implementação de Estratégia de Dados (25 questões). 

Melhores Práticas em Gestão de Recursos de Dados (20 questões). 

Fundamentos de Qualidade dos dados (25 questões). 

Governança de dados para Líderes Empresariais (20 questões). 

Fundamentos para Gestores de Dados (20 questões). 

Eletivo 

Um exame adicional a partir de qualquer assunto relacionado a dados, tais como 
Melhores Práticas no Gerenciamento de Recursos de Dados, Data Warehouse, 
Business Intetligence, dentre outros 


Tabela 13.3 - Quadro de exames CIMP 

Adaptado de http://ecm.elearningcurve.com/Online_CIMP_Certification_s/93.htm 


O DAMA autoriza o programa de Certificado de Gestão de Dados - 
CDMP em parceria com o Instituto de Certificação de Profissionais de Infor¬ 
mática (ICCP), que administra testes e recertificação. 

Há duas categorias de certificação CDMP: Practitioner CDMP e CDMP 
Mastery. 

A certificação Practitioner CDMP é concedida aos profissionais que pon¬ 
tuaram acima de 50% em todos os três exames do ICCP. Essa certificação 
habilita o profissional a fazer parte da equipe de governança de dados. 

A certificação CDMP Mastery é concedida aos profissionais que mar¬ 
caram 70% ou mais em todos os três exames. Essa certificação habilita o 
profissional a liderar e orientar uma equipe de profissionais de governança 
de dados. 
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O CDMP requer três exames ICCP: o primeiro exame trata das questões 
fundamentais do gerenciamento de dados. O tema do segundo exame é de 
escolha do candidato. Ambos os exames sáo obrigatórios. 

O terceiro exame é dependente da experiência de trabalho do candidato. 
As opções são: 

□ Data Warehousing. 

□ Business Intelligence. 

□ Qualidade de Dados e Informação. 

□ Desenvolvimento de Dados. 

□ Administração de Banco de Dados. 

□ Zachman Enterprise Architecture Framework. 

□ Gerenciamento de Projetos integrados de TI. 

Se há a intenção de demonstrar experiência em áreas especificas, o ICCP 
emitirá a certificação de Expert ( Proficiency ) para cada exame de especialidade 
com aproveitamento de 70% ou mais. 

Maiores informações podem ser conseguidas em http://www.dama.org/ 
i4a/pages/index.cfm?pageid=3399. 




Novas Tecnologias e a Governança 
de TI 


O surgimento de novas tecnologias ou novos usos de recursos e serviços de 
tecnologia da informação vem transformando o papel e a estrutura das áreas 
de TI das organizações. 

Principalmente no tocante às organizações privadas (sejam com fins lu¬ 
crativos ou não), a utilização de recursos e serviços “sob demanda” tem au¬ 
mentado consideravelmente. Em outras palavras, à medida que os serviços 
começam a ser mais confiáveis, mais e mais organizações optam por realizar 
outsourcing da infraestrutura tecnológica, de serviços de TI e de aplicações de 
gestão empresarial (. Enterprise Resource Planning). 

Apesar dessa tendência, todos os processos de Governança de TI ainda 
permanecem aplicáveis e os processos de gestão de TI mudam de ênfase e 
foco. 

Neste cenário, quatro “novas tecnologias” que têm sido muito comentadas 
e estão começando a ser aplicadas pelas organizações ( cloud computing , big 
data , mídias sociais e bringyour own device - BYOD) serão exploradas neste 
capítulo quanto ao seu impacto na Governança de TI. 


14.1 Cloud Computing 

14 . 1.1 O que É Cloud Computing 

De acordo com o National Institute ofStandards and Technology da Secre¬ 
taria de Comércio do Governo dos Estados Unidos [NIST (2011)], cloud 
computing ou computação em nuvem é: 
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Um modelo para permitir o acesso conveniente, sob demanda, a uma rede 
com um conjunto compartilhado de recursos de computação configuráveis 
( íx: redes, servidores, armazenamento, aplicações e serviços), que podem 
ser rapidamente provisionados e liberados com o mínimo de esforço geren¬ 
cial e interação com o provedor de serviço. 

Ainda de acordo com o NIST, as principais caraterísticas da nuvem sáo: 

□ Autoatendimento sob demanda : significa que o “consumidor” pode 
provisionar capacidades computacionais, tais como tempo de servi¬ 
dores e espaço de armazenamento, de forma automática, sem a neces¬ 
sidade de interação humana com o provedor de serviço. 

□ Acesso amplo à rede : a rede de nuvem deve ser acessível em qualquer 
lugar, em quase todos os dispositivos (por exemplo, smartphones, lap- 
tops, PDAs e outros aparelhos portáteis). 

□ Grupo de recursos : o provedor de recursos de computação é agru¬ 
pado para atender a vários clientes, usando um modelo multicliente 
com diferentes recursos físicos e virtuais alocados dinamicamente e 
realocados de acordo com a demanda. Há um senso de independên¬ 
cia local. Geralmente, o cliente náo tem nenhum controle ou conhe¬ 
cimento sobre a localização exata dos recursos disponibilizados. No 
entanto, é possível especificar o local em um nível maior de abstração 
(por exemplo, país, região ou central de dados). Exemplos de recursos 
incluem o armazenamento, o processamento, a memória, a largura de 
banda da rede e as máquinas virtuais. 

□ Rápida elasticidade : os recursos podem ser provisionados rapidamen¬ 
te e de forma elástica, em muitos casos de forma automática, para 
aumentar em escala rapidamente e também reduzir de forma rápida. 
Para o cliente, os recursos disponíveis para o fornecimento muitas 
vezes parecem ser ilimitados e podem ser adquiridos em qualquer 
quantidade a qualquer momento. 

□ Serviço medido : os sistemas de nuvem controlam e aperfeiçoam au¬ 
tomaticamente a utilização de recursos, aproveitando a capacidade de 
medição (por exemplo, armazenamento, processamento, largura de 
banda e contas de usuários ativas). O uso de recursos pode ser moni¬ 
torado, controlado e reportado, oferecendo transparência tanto para 
o provedor quanto para o cliente do serviço utilizado. 
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Os principais modelos de serviços sáo: 

□ Infraestrutura como um serviço (IaaS) : capacidade de fornecer pro¬ 
cessamento, armazenamento, redes e outros recursos fundamentais 
de computação, oferecendo ao cliente a possibilidade de implantar 
e executar software em geral, que pode incluir sistemas operacionais 
e aplicativos de sua propriedade. O cliente não gerencia ou controla 
a infraestrutura, mas tem controle sobre os sistemas operacionais, 
gerenciamento do armazenamento e sobre as aplicações e possivel¬ 
mente controle limitado sobre certos componentes da rede como 
fireivalls. 

□ Plataforma como um serviço (PaaS) : a capacidade de fornecer ao 
cliente a possibilidade de criar sua própria nuvem ou aplicações ad¬ 
quiridas criadas usando linguagens, bibliotecas, serviços e ferramen¬ 
tas suportadas pelo fornecedor de serviços. O cliente não gerencia 
ou controla a infraestrutura de nuvem, incluindo redes, servidores, 
sistemas operacionais ou armazenamento, mas tem controle sobre as 
aplicações implantadas e possivelmente sobre os parâmetros da confi¬ 
guração do ambiente de hospedagem das aplicações. 

□ Software como um serviço (SaaS) : a capacidade fornecida ao cliente 
de usar as aplicações proprietárias que são processadas na infraestru¬ 
tura de nuvem. As aplicações são acessíveis a partir de vários disposi¬ 
tivos do cliente, seja através de um browser ou interface programada. 
O cliente não gerencia ou controla a infraestrutura de nuvem, in¬ 
cluindo redes, servidores, sistemas operacionais, armazenamento ou 
aplicações individuais, com possibilidade limitada de parâmetros de 
configuração de aplicações. 

A infraestrutura de nuvem pode ser disponibilizada em uma nuvem priva¬ 
da, comunitária, pública ou híbrida. 

□ Nuvem privada : a infraestrutura é provisionada para uso exclusivo de 
uma única organização, contemplando múltiplas unidades de negó¬ 
cio. Pode ser de propriedade, gerenciada e operada pela organização, 
por uma terceira parte contratada ou uma combinação de ambos, 
podendo ser local ou não. 
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□ Nuvem comunitária : a infraestrutura de nuvem é provisionada para 
uso exclusivo de uma comunidade de clientes de organizações que 
compartilham preocupações comuns em termos de missão, requisitos 
de segurança, política e considerações de conformidade. Pode ser de 
propriedade, gerenciada e operada por uma ou mais organizações da 
comunidade, por uma terceira parte ou combinação de ambos. 

□ Nuvem pública : a infraestrutura é provisionada para uso pelo público 
em geral. Pode ser de propriedade, gerenciada e operada por um ne¬ 
gócio, organização governamental, por uma organização acadêmica 
ou alguma combinação dessas organizações. Existe somente nas pre¬ 
missas do provedor da nuvem. 

□ Nuvem híbrida : uma composição de duas ou mais nuvens (privada, 
pública ou comunitária) unidas por uma tecnologia padronizada 
ou de seu proprietário, permitindo a portabilidade de dados e apli¬ 
cativos, mas que permanecem como entidades únicas e exclusivas 
(aplicável, por exemplo, no balanceamento de carga entre nuvens 
requerido por um evento de estouro de capacidade em uma nuvem). 

Por fim, os principais benefícios atribuídos à computação em nuvem são: 

□ Mudança dos gastos de TI de investimentos para despesas operacionais. 

□ Menor necessidade por vultosos investimentos em TI. 

□ Realocação de recursos para processos de negócio chaves. 

□ Aquisição de aplicações que são fáceis e baratas para implementar, 
usadas e que têm suporte técnico adequado. 

□ Aumento de escalabilidade e flexibilidade no uso de recursos 
computacionais. 

□ Diminuição do esforço gerencial no gerenciamento de serviços de TI. 

□ Redução drástica dos custos de TI. 


14 . 1.2 Perguntas que os executivos de negócio devem 

FAZER PARA DECIDIR SOBRE A COMPUTAÇÃO EM NUVEM 

Como qualquer escolha e investimento em tecnologia da informação, a 
computação em nuvem também deve ser governada. O uso do termo “go¬ 
vernada” aqui significa que é preciso obter os benefícios da computação em 
nuvem para o negócio a um nível de risco aceitável para a empresa. 
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Do ponto de vista da alta administração, as seguintes perguntas devem ser 
respondidas: 

1. Os executivos de TI e de negócios têm um plano para a adoção da 
computação em nuvem? 

2. Os custos e benefícios foram avaliados? 

3. O plano de adoção da computação em nuvem está alinhado com a 
missão e os objetivos da organização? 

4. A prontidão da organização para a adoção da computação em nuvem 
foi avaliada? 

5. Foi considerado o investimento já realizado que vai ser perdido pela 
adoção da computação em nuvem? 

6. Há estratégias para medir se os benefícios planejados estão sendo 
alcançados? 

7. Os riscos foram identificados e avaliados? 

8. Como os riscos serão gerenciados? 

9. Quais capacidades de gestão a empresa deve adquirir para lidar com 
a computação em nuvem? 

10. Como as informações da empresa estarão asseguradas? 

14 . 1.3 Principais riscos 

Os riscos de uso da computação em nuvem estão associados à proteção dos 
ativos e informação da empresa, portanto, a questões de segurança da infor¬ 
mação em um sentido mais amplo. 

Em estudo realizado em 316 empresas para identificar os principais riscos 
de segurança no uso da computação em nuvem no Japão [Harada (2011)], os 
seguintes riscos foram apontados: 

□ Aplicações proprietárias : possibilidade da conversão de dados para 
outros formatos não ser permitida. 

□ Perda de governança : todos os processos de negócio estão sob a gestão 
do provedor de serviços e não podem ser alterados pela gerência da 
empresa. 

□ Desafios de compliance : se o provedor de serviços violar leis e requi¬ 
sitos de compliance , o cliente automaticamente pode ser envolvido. 






552 Implantando a Governança de TI - 4 a edição 


□ Perda de reputação da empresa, devido a atividades de outros clientes 
que utilizam os serviços do mesmo provedor. 

□ Término ou encerramento do serviço : risco do provedor não fornecer 
mais o serviço. 

□ Aquisição do provedor do serviço por um concorrente : pode haver 
problemas no fornecimento de serviços em termos de qualidade e 
continuidade. 

□ Falha na cadeia de valor dos serviços de nuvem, podendo interrom¬ 
per os serviços para a empresa. 

□ Exaustão de recursos : a modelagem imprecisa de capacidade e dis¬ 
ponibilidade de recursos, assim como de algoritmos de alocação de 
recursos, pode degradar a disponibilidade e o tempo de resposta. 

□ Falha de isolamento : falha do mecanismo que separa memória, ar¬ 
mazenamento e roteamento entre os clientes que compartilham os 
mesmos recursos. 

□ Intrusão maliciosa ou papéis com altos privilégios de acesso : intrusão 
de dentro do provedor de serviços. 

□ Gerenciamento da interface compromissada : acesso via Internet, 
acesso remoto e vulnerabilidades dos browsers podem afetar a segu¬ 
rança dos serviços e as aplicações usadas pela empresa. 

□ Interceptação de dados, perda de dados : quando os dados são distribuí¬ 
dos entre várias nuvens ou entre servidores dispersos geograficamente. 

□ Deleçáo de dados insegura ou incompleta : o provedor não faz total¬ 
mente a deleção de dados solicitada. 

□ Perda de chaves encriptadas : acesso de partes maliciosas às chaves ou 
senhas secretas pode implicar na perda de dados . 

□ Escaneamento malicioso : ameaça indireta aos ativos de informação. 

□ Gerenciador de serviços compromissados : pode ter vulnerabilidades e 
está inclinado a sofrer ataques ou falhas inexplicadas. 

□ Conflitos entre procedimentos antigos e o ambiente de nuvem : pode 
criar vulnerabilidades no fornecimento do serviço pelo provedor. 

□ Intimação : como resultado de uma intimação, dados armazenados e 
discos compartilhados podem ser expostos a terceiras partes por força 
de lei e o usuário pode não conseguir preservar ou proteger uma evi¬ 
dência, quando requerido pelas autoridades. 

□ Risco de mudança de jurisdição : os dados podem estar distribuídos 
em vários locais com requisitos legais diferentes. 



















Novas Tecnologias e a Governança de TI 553 


□ Condições de licenciamento : podem náo funcionar ou ser inviáveis 
em um ambiente de nuvem. 

□ Queda da rede de comunicação : afeta todos os clientes do provedor. 

□ Gerenciamento da rede : falha do provedor no gerenciamento da rede. 

□ Logs operacionais e de segurança : o provedor pode perder esses logs. 

□ Perda de backups por parte do provedor. 

□ Acesso náo autorizado às instalações : pode comprometer a operaçáo 
do provedor. 

□ Roubo de equipamentos nas instalações do provedor. 

□ Desastres naturais : interrupção no fornecimento de serviços pelo pro¬ 
vedor devido a inundações, tempestades etc. 


14.1.4 Processos de governança e de gestão que devem 

SER REFORÇADOS 

Considerando os aspectos da computação em nuvem descritos até agora, é 
importante evidenciar como devem se comportar os processos de governança 
e gestão de TI neste cenário, tomando como base os processos do CobiT 5. 

Enfatizamos que, independentemente do nível de outsourcing das ativida¬ 
des de TI de uma empresa, a ESTRATÉGIA DE TI é tarefa indelegável em 
qualquer cenário. 

A Tabela 14.1 apresenta nossa apreciação sobre a questão. 


Domínios de Processos 

Processos 

Impacto da Computação em Nuvem 

EDM 

(Avaliar, Dirigir e Monitorar) 

EDM01 - Assegurar 
o estabelecimento 
e a manutenção 
do frameworkde 
governança 

As questões de direito decisórias e definição de 
responsabilidades são mantidas em qualquer 
cenário. 


EDM02 - Assegurar a 
entrega dos benefícios 

Qualquer tipo de investimento em TI ou que tenha 

TI como seu elemento principal deve ser avaliado 
quanto ao seu retorno e depois deve ser verificado 
se o retorno foi, de fato, obtido. 


EDM03-Assegurar a 
otimização dos riscos 

Uma mudança para a computação em nuvem 
tem vários riscos para a empresa. Portanto, a 
tolerância aos riscos deve ser determinada junto aos 
executivos de negócio, e ações de mitigação e de 
contingência devem ser estabelecidas e implantadas. 
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Domínios de Processos 

Processos 

Impacto da Computação em Nuvem 

EDM 

(Avaliar, Dirigir e Monitorar) 

EDM04-Assegurar 
a otimização dos 
recursos 

Quem estabelece os requisitos e as especificações 
dos serviços e abordagens de nuvem é a empresa. 
Nem toda arquitetura oferecida por provedores de 
serviços é otimizada. A alocação e o uso de recursos 
devem ser monitorados e avaliados periodicamente. 


EDM05-Assegurar a 
transparência para as 
partes interessadas 

0 negócio necessita ter informações sobre o 
desempenho da TI e de seu valor e impacto para o 
negócio em qualquer cenário. 

APO 

(Alinhar, Planejar e 

Organizar) 

APOOI - Gerenciar o 
Framework de Gestão 
de TI 

Definição e manutenção da estrutura de TI, 
políticas, papéis e responsabilidades do pessoal de 
TI. A compliance deve ocorrer em qualquer cenário. 


APO02 - Gerenciar a 
estratégia 

A estratégia de TI é indelegável, como falamos 
anteriormente. A definição de objetivos estratégicos 
de TI, seu alinhamento com o negócio e o 
desdobramento em metas e iniciativas se mantêm 
com ou sem computação em nuvem. 


APO03- Gerenciar a 
arquitetura corporativa 

0 planejamento, o desenvolvimento e a implantação 
da arquitetura de serviços também são indelegáveis. 
A empresa pode ter ajuda externa para isso, mas a 
decisão de fazer é dela. 


APO04 - Gerenciar a 
inovação 

Definir o direcionamento tecnológico de TI para 
a competitividade da empresa também é de 
responsabilidade indelegável. A empresa também 
pode ter ajuda para esse direcionamento. 

Grandes usuários de TIC geralmente contratam 
serviços de empresas como Gartner Group 
e Forrester Group, cujos analistas fornecem 
orientação e consultoria. 


APO05 - Gerenciar o 
portfólio 

Este processo é um dos mais importantes para 
o gerenciamento de todas as demandas sobre 

TI. É ele que faz a ligação entre a estratégia e a 
execução, além de apoiar processos de governança 
como o de assegurar a entrega de benefícios. 
Portanto, serviços em nuvem também fazem parte 
do portfólio e o seu gerenciamento é da empresa. 


APO06 - Gerenciar 
orçamento e custos 

Este processo é de responsabilidade da empresa, 
e também indelegável, e tem a ver com o processo 
de otimização de recursos. Uma boa gestão de 
contratos e fornecedores pode apoiar uma gestão 
de custos mais efetiva. 


APO07 - Gerenciar 
recursos humanos 

Geralmente este é um processo corporativo 
onde a TI está inserida. Mas, de qualquer forma, 
o CIO deve atentar para manter os talentos ou 
pessoas chaves para o sucesso de sua missão e 
visão (alinhada com os objetivos estratégicos da 
empresa). 
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Domínios de Processos 

Processos 

Impacto da Computação em Nuvem 

APO 

(Alinhar, Planejar e 

Organizar) 

APO08 - Gerenciar 
relacionamentos 

0 relacionamento entre TI e as áreas de negócio 
acontece em qualquer cenário. 


APO09 - Gerenciar 
acordos de serviço 

Uma boa TI deve ter acordos de níveis de serviços 
com as áreas de negócio e que são restrições para 
os serviços fornecidos pelo provedor de nuvem. Em 
outras palavras, os acordos de níveis de serviços da 
TI para o negócio definem os requisitos de serviços 
para a nuvem. 


APOIO -Gerenciar 
fornecedores 

Processo que deve ser bastante reforçado no 
cenário de computação em nuvem. 


AP011 - Gerenciara 
qualidade 

Medir a qualidade dos produtos e serviços de 

TI é importante para a melhoria contínua e para 
a otimização de recursos. Isso deve ocorrer em 
qualquer cenário. 


AP012- Gerenciar 
riscos 

0 processo de governança “EDM03 - Assegurar 
a otimização de riscos” depende deste processo. 

Com a computação em nuvem sendo provida por 
fornecedor de serviço externo, a gestão de riscos 
deve ser contínua. 


APOI3 -Gerenciar a 
segurança 

Como a segurança da informação é um elemento 
importante em um cenário de computação em 
nuvem, a definição do sistema de gerenciamento 
da segurança e de políticas e responsabilidades 
também é indelegável. Serviços operacionais de 
segurança da informação podem ser terceirizados. 

BAI 

(Construir, Adquirir e 
Implementar) 

BAI01 - Gerenciar 
programas e projetos 

Processo fundamental que concretiza a estratégia 
de TI e de negócio. Ocorre em qualquer cenário de 
computação em nuvem. 


BAI02 - Gerenciar a 
definição de requisitos 

Processo indelegável. A empresa pode até ter ajuda 
para isso, porém o veredicto é da empresa, se 
aceita ou não os requisitos e recomendações. 


BAI03 - Gerenciar 
a identificação e a 
construção de soluções 

A execução deste processo pode ser terceirizada, 
mas a empresa também tem a palavra final. 


BAI04 - Gerenciar 
disponibilidade e 
capacidade 

Em um cenário de computação em nuvem, este é 
um processo que pode ser executado integralmente 
pelo fornecedor de serviços. 


BAI05 - Gerenciar 
a habilitação 
da mudança 
organizacional 

Processo também indelegável e de responsabilidade 
da empresa. Por exemplo, mudanças que podem 
ocorrer em função da implantação de um sistema 
integrado de gestão na empresa devem ser 
planejadas e gerenciadas pela empresa. 
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Domínios de Processos 

Processos 

Impacto da Computação em Nuvem 

BAI 

(Construir, Adquirir e 
Implementar) 

BAI06 - Gerenciar 
mudanças 

Dependendo do tipo de serviço de nuvem, pode 
ser um processo totalmente sob a responsabilidade 
do fornecedor de serviços, principalmente na 
abordagem de SaaS. 


BAI07 - Gerenciar o 
aceite e a transição de 
mudanças 

É um processo compartilhado com o fornecedor 
de serviços. Podem ser estabelecidos padrões de 
qualidade para fins de aceitação de produtos e 
serviços estabelecidos em contrato. 


BAI08 - Gerenciar o 
conhecimento 

Processo que pode ocorrer na empresa e no 
fornecedor, independentemente. 


BAI09 - Gerenciar 
ativos 

Se todos os recursos computacionais forem 
do fornecedor, então este processo é de sua 
responsabilidade integral, com exceção dos dados 
que são da empresa. 


BAI10- Gerenciar a 
configuração 

Se todos os serviços, infraestrutura e aplicações 
estiverem no fornecedor, principalmente na 
abordagem SaaS, a responsabilidade é totalmente 
dele. 

DSS 

(Entregar, Reparar e 

Suportar) 

DSS01 - Gerenciar 
operações 

De responsabilidade do fornecedor, naquilo que 
estiver no contrato de fornecimento de serviços. 


DSS02 - Gerenciar 
requisições de serviços 
e incidentes 

De responsabilidade do fornecedor, naquilo que 
estiver no contrato de fornecimento de serviços. 


DSS03- Gerenciar 
problemas 

De responsabilidade do fornecedor, naquilo que 
estiver no contrato de fornecimento de serviços. 


DSS04 - Garantir a 
continuidade 

0 fornecedor deve ter um plano de continuidade 
de serviços e de desastre e recuperação, que 
deve constar em um contrato e ser aprovado e 
monitorado pela empresa. 


DSS05 - Gerenciar os 
serviços de segurança 

De responsabilidade do fornecedor, naquilo que 
estiver no contrato de fornecimento de serviços. 

0 serviço deve ser periodicamente avaliado pela 
empresa. 


DSS06- Gerenciar 
controles de processos 
de negócios 

Trabalho conjunto entre a empresa e o fornecedor. 
Pode haver restrições de controle em ambientes 
SaaS, pois a empresa pode ter limitações na 
configuração dos aplicativos quanto aos controles e 
privilégios de acesso. 

MEA 

(Monitorar, Avaliar e Medir) 

MEA01 - Monitorar, 
avaliar e medir o 
desempenho e a 
conformidade 

De responsabilidade integral da empresa. 

Requisitos de compliance podem estar presentes 
no contrato de prestação de serviços e serem 
monitorados. 
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Domínios de Processos 

Processos 

Impacto da Computação em Nuvem 

MEA 

(Monitorar, Avaliar e Medir) 

MEA02 - Monitorar, 
avaliar e medir o 
sistema de controles 
internos 

De responsabilidade integral da empresa. 

MEA03 - Monitorar, 
avaliar e medir a 
conformidade com 
requisitos externos 

De responsabilidade integral da empresa. 

Requisitos devem estar presentes no contrato com 
o fornecedor e ser monitorados periodicamente 
através de auditorias próprias ou contratadas para 
este fim. 


Tabela 14.1 - Impactos da computação em nuvem na governança de TI 


14.2 Big Data 

14.2.1 O que É Big Data 

De acordo com Siewert (2013), Big Data é: 

Definido genericamente como a captura, gerenciamento e a análise de 
dados que vão além dos dados tipicamente estruturados, que podem ser 
consultados e pesquisados através de bancos de dados relacionais. Frequen¬ 
temente são dados obtidos de arquivos não estruturados como vídeo digital, 
imagens, dados de sensores, arquivos de logs e de qualquer tipo de dados 
não contidos em registros típicos com campos que podem ser pesquisados. 

Ainda de acordo com este autor, o Big Data tem variadas fontes de dados 
como: 

□ Dados gerados pelas máquinas (redes de sensores, logs). 

□ Dispositivos móveis (vídeo, mensagens, fotografias). 

□ Comunicação máquina a máquina, a “Internet das coisas”. 

□ Dados em bancos de dados relacionais oriundos das transações da 
organização. 

□ Imagens de documentos, etc. 

O objetivo do Big Data é propiciar dados e informações que possam ser 
analisados visando subsidiar tomadas de decisão. 
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A tomada de decisão é possível em função não somente do volume de 
dados, da velocidade de captura dessas informações, das fontes variadas de 
informações e de novos softwares para fins de modelagem dessas informações. 
Por exemplo, ver uma tendência de crescimento da venda de um produto em 
função de comentários favoráveis no Facebook. Este tipo de análise é o que 
está sendo denominado data analytics. 

O que se apregoa é que de nada adianta você armazenar uma montanha de 
dados se não sabe como tirar proveito disso para o negócio. 

Quando se fala em grandes volumes de informações, deve-se atentar para 
os volumes apresentados a seguir, gerados pela sociedade da informação atual: 

□ Em 2012, de acordo com o IDC — ver Gantz & Reinsel (2012), fo¬ 
ram gerados 2,7 zettabytes 124 de informações no mundo. 

□ Para 2015, espera-se a geração de 8 zettabytes. 

Outros dados curiosos 125 : 

□ Mais de dois bilhões de seres humanos são usuários da Internet. 

□ 225 milhões são usuários do Linkedln. 

□ 751 milhões são usuários do Facebook em plataformas móveis. 

□ Mais de 1,1 bilhão são usuários ativos no Facebook (em 2011 este 
número era a metade). 

□ Mais de 500 milhões de usuários possuem conta no Twitter, sendo 
140 milhões de contas ativas. 

□ 100 horas de vídeo são postadas por minuto no YouTube 126 . 

As aplicações do Big Data e da análise de dados são variadas como: 

□ Desenvolvimento de mercado. 

□ Inovação. 

□ Desenvolvimento de produtos e serviços. 

□ Eficiência operacional. 

□ Previsões de demanda de mercado. 


124 Um Zettabyte representa 1 180 591 620 717 411 303 424 (270) bytes. 

125 Com certeza, quando você estiver olhando para esses números eles já estarão desatualizados... 

126 Fonte: artigo em http://info.abril.com.br/noticias/internet, publicado em 19/05/2013. 
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□ Detecção de fraudes. 

□ Gerenciamento de riscos. 

□ Previsão de concorrência. 

□ Vendas. 

□ Campanhas de marketing. 

□ Avaliação do desempenho de funcionários. 

□ Alocação do orçamento anual. 

□ Estabelecimento de previsões financeiras. 

□ Gestão de planos médicos. 

□ Identificação de potenciais compradores. 

□ Entendimento da base de clientes etc. 

Uma análise conjunta do IBMInstitute for Business Value e do Massachussets 
Institute of Technology (o famoso MIT) identificou que empresas que investem 
em análise de dados ( Business Analytics and Optimization ) possuem uma visão 
melhor do seu negócio, conseguindo uma receita 33% maior do que seus 
concorrentes, crescimento do lucro doze vezes maior e retorno sobre o inves¬ 
timento de capital 32% maior [IBM (2011)]. 


14.2.2 Perguntas que os executivos de negócio devem 

FAZER PARA DECIDIR SOBRE O EMPREGO DO BlG DATA 

1. Os executivos de TI e de negócios têm um plano para a adoção do 
Big Data ? 

2. Os custos e benefícios foram avaliados? 

3. O plano de adoção do Big Data está alinhado com a missão e os ob¬ 
jetivos da organização? 

4. Devemos desenvolver as competências ou contratar serviços? 

5. Foi considerado o investimento já realizado em Data Warehouse e 
Business Intelligence ? 

6. Há estratégias para medir se os benefícios planejados estão sendo 
alcançados? 

7. Os riscos foram identificados e avaliados? 

8. Como os riscos serão gerenciados? 

9. Quais capacidades de gestão a empresa deve adquirir para lidar com 
o Big Data ? 
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10. Como as informações da empresa e de clientes estarão asseguradas? 

11. Como será garantida a qualidade dos dados capturados? 

12. Os dados serão categorizados e modelados? 

13. Como os modelos de análise serão desenvolvidos e mantidos? 

14. Quais capacitações são necessárias para o pessoal que irá lidar com o 
Big Datai 

14.2.3 Riscos principais 

De acordo com a ISACA (2013a), as principais perguntas que devem ser 
feitas em relação ao Big Data, do ponto de vista dos riscos, são: 

□ Onde os dados serão armazenados? 

□ Como os dados serão protegidos? 

□ Como utilizar os dados de forma segura e legal? 

Os principais riscos que devem ser gerenciados são: 

□ Riscos de perda de dados “tóxicos” armazenados como informações 
privadas ou de custódia, tais como contas de clientes, números de car¬ 
tão de crédito, fórmulas e demais segredos industriais da empresa etc. 

□ O uso de informações obtidas em redes sociais, por exemplo, abrange 
questões de privacidade e de falta de consenso jurídico internacional, 
uma vez que cada país tem sua legislação específica. 

□ Questões de segurança da informação. 

□ Qualidade dos dados capturados para fins de análise. 

□ Disponibilidade e capacidade da infraestrutura tecnológica que su¬ 
porta o Big Data. 

□ Qualidade e capacidade do fornecedor de serviços (se for o caso) que 
captura, armazena e/ou realiza análise de dados. 

□ Qualidade dos modelos de exploração desenvolvidos para a análise 
dos dados. 

□ Pessoas com capacitação requerida (cientista de dados 127 ) para desen¬ 
volver modelos e analisar resultados. 


127 Vide o Blog do Cezar Taurion - www.ibm.com/developerworks. De acordo com Taurion, o cientista 
de dados é um profissional capacitado em estatística, ciência da computação e/ou matemática, com 
grande entendimento do negócio, capaz de analisar grandes volumes de dados e extrair deles insights 
que criem novas oportunidades de negócio. 
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□ Falha ao categorizar e mapear os dados. 

□ Falta de Governança de Dados. 


14.2.4 Processos de governança e de gestão afetados 

Conforme descrito no Capítulo 13 deste livro, a Data Management Asso- 
ciation desenvolveu um framework específico denominado The DAMA Guide 
to the Data Management Body of Knowlege - DMBOK Guide. Uma das áreas 
de conhecimento deste framework é justamente a Governança de Dados, que 
abrange o planejamento, a supervisão e o controle sobre o gerenciamento de 
dados e do seu uso. 

Do ponto de vista do CobiT 128 , as preocupações no contexto do Big Data 
podem ser classificadas em três dimensões: 

□ Variedade de informações, derivada da multiplicidade de fontes de 
informação existentes. 

□ Velocidade da criação de informações, aspecto a ser considerado, por 
exemplo, na prevenção de fraudes, que podem envolver múltiplas 
transações em curtos períodos de tempo. 

□ Volume de informações , resultante do aumento da variedade e da 
velocidade das informações. 

Alguns dos processos que devem ser reforçados para tratá-las são: 

□ Todos os processos de governança - EDM01, EDM02, EDM03, 
EDM04 e EDM05 (vide Tabela 14.1). 

□ O processo APQ03 - Gerenciar a arquitetura corporativa , pois tam¬ 
bém trata da arquitetura de dados, categorização e mapeamento. 

□ O processo APQ04 - Gerenciar a inovação , pois trata da aquisição de 
novos conhecimentos e estabelecimento das tecnologias a serem usadas. 

□ O processo APQ07 — Gerenciar recursos humanos, pois os “cientistas 
de dados” devem ser formados e mantidos. 

□ O processo APOQ9 - Gerenciar acordos de serviço , tanto interna¬ 
mente como com fornecedores de serviços de análise de dados. 


128 Vide publicação CobiT 5: Enabling Information [ISACA(2013b)]. 
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□ O processo APOIO - Gerenciar fornecedores , se forem contratados 
serviços relacionados ao Big Data. 

□ O processo APQ12 — Gerenciar riscos , conforme já apontamos 
anteriormente. 

□ O processo APQ13 - Gerenciar a segurança , incluindo direitos de 
propriedade. 

□ O processo BAI01 - Gerenciar programas e projetos , principalmente 
porque a implantação do Big Data é um projeto e talvez até possa se 
configurar como um programa. 

□ O processo BAI02 - Gerenciar a definição de requisitos , que equivale 
a definir premissas de modelos de análise, ou seja, aquilo que o ne¬ 
gócio quer ou tem uma vaga ideia de relacionamento ou correlações 
de eventos. 

□ O processo BAI03 - Gerenciar a identificação e a construção de 
soluções, que equivale a definir a forma de implementação dos 
requisitos. 

□ O processo BAI04 - Gerenciar a disponibilidade e a capacidade, que 
são aspectos cruciais para o processamento de grandes volumes de 
informação. 

□ O processo BAI08 - Gerenciar o conhecimento , pois os dados e os 
modelos de análise devem ser guardados para futura referência. 

□ O processo BAI09 - Gerenciar ativos , notadamente os mais críticos, 
que possuem requisitos mais severos de disponibilidade e capacidade. 

□ O processo BAI10 - Gerenciar a configuração , devido à sua im¬ 
portância para as análises de relacionamentos entre os ativos de 
informação. 

□ Todos os processos dos domínios DSS e MEA (vide Tabela 14.1). 

14.3 Mídias sociais 

14.3.1 O QUE SÃO MÍDIAS SOCIAIS 

A tecnologia de mídia social envolve a criação e a disseminação de conte¬ 
údo através de redes sociais usando a Internet [ISACA (2010)]. A tecnologia 
de mídia social contempla blogs (como os criados pelo WordPress, TypePad), 
sites de relacionamento (Facebook, Myspace), micro blogs (Twitter), sites de 
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compartilhamento de vídeos e fotos (YouTube, Flickr), sites de relacionamen¬ 
to profissional (Linkedln), dentre outros. 

De acordo com a ISACA (2010), mídias sociais envolvem a criação e a 
disseminação de conteúdo através de redes sociais usando a Internet. Observe 
que, nas mídias sociais, o criador de conteúdo é o próprio usuário. 

Do ponto de vista empresarial, a tecnologia de mídias sociais pode ser 
empregada para: 

□ Conhecer melhor o cliente. 

□ Através de feedbacks dos clientes, melhorar produtos, serviços e os 
respectivos processos. 

□ Comunicar-se com os clientes. 

□ Desenvolver relacionamentos com os clientes. 

□ Criar reputação de marca. 

□ Monitorar a concorrência. 

□ Comunicar-se com empregados potenciais. 

□ Desenvolver, de forma colaborativa, produtos e serviços, dentre ou¬ 
tras aplicações. 

Em algumas organizações são estruturadas redes sociais internas, usando os 
mesmos tipos de redes e aplicações, inclusive comunicação instantânea. 


14.3.2 Perguntas que os executivos de negócio devem 

FAZER PARA DECIDIR SOBRE EXPLORAR AS TECNOLOGIAS SOCIAIS, 
VISANDO ATENDER A OBJETIVOS ESTRATÉGICOS ATRAVÉS DO 
RELACIONAMENTO VIRTUAL COM OS CLIENTES 

As principais questões que devem ser levantadas e respondidas são: 

1. Qual é o benefício estratégico de usar as mídias sociais pela organização? 

2. Todos os interessados relevantes estão envolvidos com a definição da 
estratégia? 

3. Quais são os riscos para a organização com o uso de redes sociais in¬ 
ternamente e externamente? 

4. Quais são as questões legais relacionadas com o uso das redes sociais? 

5. Como a questão da privacidade do cliente será tratada? 
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6. Como o reconhecimento positivo da marca poderá ser assegurado? 

7. Qual competência devemos ter para usar as mídias sociais de forma 
competitiva? 

8. Como reclamações de clientes serão tratadas? 

9. Como se dará a governança? 

10. Quais sáo os gastos necessários em termos de investimentos e despesas 
operacionais? 

11. Como os benefícios do uso das mídias sociais seráo avaliados? 

12. Como ficaráo as responsabilidades pela gestão das mídias sociais? 

14.3.3 Riscos principais 

Como a introdução do uso de mídias sociais na organização pode ser fei¬ 
ta com pouco ou nenhum investimento significativo, sem a interferência da 
área de TI e sem planos de riscos, pode criar vulnerabilidades para o negócio, 
descritas a seguir: 

□ O foco do uso pela empresa é estritamente para comunicar-se com os 
clientes; entretanto, demora em demasia na resolução de reclamações 
ou citações negativas, pois não tem um processo estruturado, afetan¬ 
do sua reputação junto ao mercado. 

□ A empresa demora em demasia para alterar processos, produtos e ser¬ 
viços, também afetando sua reputação. 

□ As comunicações realizadas pela empresa em várias mídias simultanea¬ 
mente podem não estar sincronizadas, criando confusão na mente 
dos clientes. 

□ Questões de direitos autorais e permissões de uso das informações, 
vídeos e fotos da empresa quando se usa, por exemplo, Google, 
Facebook etc. 

□ Comunicação inapropriada na rede, podendo criar questões jurídicas 
(como, por exemplo, denúncias de racismo, homofobia etc.). 

□ Responsabilidade pela comunicação (se é opinião da empresa ou não). 

□ Comunicação de material ou informações confidenciais nas redes 
sociais. 

□ Contas falsas da empresa nas redes sociais. 

□ Necessidade de reter as informações para atender a dispositivos legais. 
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Outro aspecto que tem preocupado as organizações é o uso de redes sociais 
pelos empregados no ambiente de trabalho. Os principais riscos nesse caso sáo 
relacionados à segurança da informação, tais como: 

□ Exposição de dados e informações dos clientes que interagem com a 
organização pela rede. 

□ Ataques a sites de clientes a partir da conta da organização na rede. 

□ Uso de contas pessoais para falar sobre a organização onde trabalha. 

□ Uso de informações, fotos e vídeos da empresa nas contas pessoais 
dos empregados 

□ Uso excessivo das mídias sociais em ambiente de trabalho. 

Para lidar com essas questões, são sugeridas as seguintes iniciativas: 

□ Definir um plano e estratégia para uso de mídias sociais pela organi¬ 
zação [Monteiro & Azarite (2012) 129 ]. 

□ Implantação de políticas sobre o uso de mídias sociais pela organiza¬ 
ção e seus empregados. 

□ Incorporar na política e no sistema de gerenciamento da segurança da 
informação as questões relativas ao uso de mídias sociais pelos funcio¬ 
nários, no ambiente de trabalho e fora dele. 

Alguns exemplos de políticas são: 

□ Não realizar divulgações não autorizadas de informações da organização. 

□ Obter permissões para usar material e informações da organização. 

□ Não usar linguagem discriminatória, de intimidação ou ofensiva. 

□ Toda a comunicação deve ser livre de assédio relativo a raça, gênero, 
religião, etnia, orientação sexual, características físicas ou outra clas¬ 
sificação protegida. 

□ Não fazer declarações falsas ou não fundamentadas. 

□ Solicitações de informações pela imprensa devem ser encaminhadas 
para a área de comunicação da organização. 

□ Uso de mídia social de contas pessoais não é permitido no horário 
normal de trabalho, conforme o contrato ou convenção trabalhista. 

129 Se você se interessa pelo uso competitivo das mídias sociais, veja este trabalho. De acordo com os 
autores, a maturidade no uso de mídias sociais pelas organizações passa em um primeiro momento pela 
plataforma de publicação, depois pelo espaço de relacionamento e, por fim, pela rede de mobilização. 
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□ Postagem pessoal deve ser feita por e-mail ou contas pessoais. 

□ Qualquer postagem pessoal sobre produtos e serviços da organização 
é altamente desencorajada etc. 


14.3.4 Processos de governança e de gestão afetados 

Do ponto de vista do CobiT 5, os processos que devem ser reforçados são: 

□ Todos os processos de Governança, tais como: EDM01, EDM02, 
EDM03, EDM04 e EDM05 (vide Tabela 14.1). 

□ O processo APQ13 - Gerenciar a segurança , incluindo direitos de 
propriedade etc. 

□ O processo BAIOS — Gerenciar o conhecimento , pois os conteúdos 
devem ser guardados para futura referência ou para fins legais. 

□ Os processos do domínio Monitorar, Avaliar e Medir (MEA), devido 
às muitas questões de controle e compliance com requisitos internos e 
externos envolvidas. 


14.4 BYOD 

14.4.1 O QUE É BYOD 

De acordo com Gajar et al. (2013), BYOD ( Bring Your Own Device) é 
um novo conceito emergente na indústria que facilita aos empregados nas 
organizações o uso de seus próprios dispositivos móveis, como smartphones e 
tablets , para ter acesso aos recursos da organização, tanto para fins de trabalho 
como para uso pessoal. 

Os dispositivos móveis são usados para enviar e receber e-mails , conversa¬ 
ções instantâneas (via Skype, WhatsApp etc.), ter acesso a aplicações corpora¬ 
tivas, à rede e a documentos. 

Conforme o Sovereign Business Integration Group (2012), nas organizações, 
em 2016: 

□ 4/5 das pessoas terão um smartphone. 

□ 4/5 das pessoas terão um tablet. 
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□ 60% dos smartphones serão de propriedade do funcionário. 

□ 70% dos tablets serão de propriedade do funcionário. 

□ Os tablets serão mais populares do que os notebooks. 

□ Tudo ou quase tudo será smarP. TV, geladeira, banheira... 

Ainda de acordo com o Sovereign Business Integration Group , as novas gera¬ 
ções que, num futuro próximo, entrarão para o mercado de trabalho, como a 
geração Y (nascidos entre 1980 e 2000) e a geração Z (nascidos após 2000), 
impulsionarão cada vez mais o BYOD, pois: 

□ Em geral não usam e-mail. 

□ Comunicam-se através de mídias sociais e aplicativos como WhatsApp. 

□ Internet é tão importante como água e comida. 

□ O Facebook geralmente é o portal para todos os sites. 

Apesar de trazerem riscos para a organização, algumas vantagens apontadas 
para o gerenciamento e uso do BYOD são: 

□ Redução dos custos de hardware para a organização, se o dispositivo 
for do próprio funcionário. 

□ Aumento da satisfação do funcionário, pois está usando o dispositivo 
de sua preferência. 

□ Podem ter acesso à informação de que necessitam a qualquer mo¬ 
mento, em qualquer lugar, a qualquer hora. 

□ Menos treinamento é necessário, pois os funcionários já lidam bem 
com essa tecnologia. 

□ Necessidade de menos suporte por parte da infraestrutura da empresa 
no caso do dispositivo ser do funcionário. 

□ Mobilidade para o funcionário. 

□ Possibilidade de aumentar a produtividade do funcionário. 

□ Aumento de colaboração entre os funcionários. 

Algumas estratégias que as organizações podem usar são: 

□ Aqui está o seu dispositivo: a organização fornece o dispositivo para 
o funcionário. O controle é total pela organização, que fornece todo 
o suporte e o configura. 
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□ Escolha o seu dispositivo: a organização fornece opções de dispositi¬ 
vos para o funcionário escolher, e o funcionário tem autorização para 
instalar determinados aplicativos. 

□ Traga o seu dispositivo: o funcionário traz o seu dispositivo e tem 
bastante liberdade; porém, deve seguir política específica para tal. Às 
vezes, a organização pode financiar parte do valor do dispositivo. Al¬ 
gum tipo de suporte pode ser fornecido pela organização. 

□ Tenha o seu dispositivo: não há controle pela organização e nem 
pelo suporte. 


14.4.2 Perguntas que os executivos de negócio devem 

FAZER SOBRE BYOD E SUA GESTÃO 

1. Qual é o benefício estratégico do BYOD? 

2. Quais políticas são necessárias para uso do BYOD? 

3. Qual é a estratégia de BYOD a ser empregada? 

4. Quais são os riscos para a organização com o uso BYOD? 

5. Quais são as questões legais relacionadas? 

6. Como monitorar o uso dos dispositivos móveis que acessam a rede 
da organização? 

7. Como a questão da privacidade do funcionário será tratada caso o seu 
dispositivo seja monitorado? 

8. Qual é a competência que devemos ter ou adquirir para gerenciar o 
BYOD? 

9. Como se dará a governança do BYOD? 

10. Quais são os gastos necessários em termos de investimentos e despesas 
operacionais? 

11. Como os benefícios do BYOD serão avaliados? 

12. Como ficarão as responsabilidades pela gestão do BYOD? 


14.4.3 Riscos principais 

De acordo com o Sovereign Business Integration Group (2012) e Gajar et al 
(2013), os principais riscos do BYOD para a organização são: 
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□ Perda de controle de atualizações de hardware e software. 

□ Resistência no cumprimento de políticas corporativas quanto ao uso 
do BYOD. 

□ Dispositivos sem gerenciamento podem causar brechas de segurança. 

□ Falha no controle de acesso à rede da organização. 

□ Recuperação de dados e informações quando o funcionário deixa a 
organização. 

□ Perda do dispositivo com informações confidenciais da organização. 

□ Perda de informações e infecção do dispositivo por vírus. 

Como se pode observar, os principais riscos concentram-se em aspectos de 
segurança da informação. 

Algumas ações que as organizações estão tomando para a mitigação desses 
riscos são o estabelecimento de políticas e a implantação do que é denomina¬ 
do de Mobile Device Management ou MDM. 

Algumas questões chaves para o estabelecimento de políticas para o geren¬ 
ciamento do BYOD são: 

□ Quem pode ser elegível para ter acesso remoto a informações, docu¬ 
mentos e aplicações da organização? 

□ Qual uso deve ser feito do dispositivo móvel pelo funcionário? 

□ Qual é o nível de privilégio? 

□ Qual é o tipo de suporte ao dispositivo fornecido pela organização? 

□ Quais as responsabilidades da organização e do funcionário? 

□ Quais serão os padrões adotados para a plataforma mobile ? 

□ Quais são os direitos da organização e do funcionário? (exemplo: a or¬ 
ganização instala software de segurança no dispositivo do funcionário). 

□ Haverá reembolso de despesas por uso dos serviços como e-mail, voz, 
torpedos etc.? 

□ Como será o tratamento para dispositivos que foram roubados ou 
perdidos? 

□ Como é tratada a necessidade de troca do dispositivo? 

□ Será permitida a mudança de configuração pelo usuário? 

□ Como será a limpeza dos dispositivos em função de mudança de pri¬ 
vilégios ou da saída do funcionário da empresa? 
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□ Quais serão as limitações de responsabilidades por parte da 
organização? 

□ O que acontecerá se a política for violada? 

O Mobile Device Management é apoiado por softwares que possibilitam 
gerenciar todos os dispositivos móveis em praticamente todos os tipos de sis¬ 
temas operacionais. 

As principais funcionalidades desses softwares são: 

□ Gerenciar os e-mails. 

□ Gerenciar o uso e compartilhamento de documentos. 

□ Gerenciar as despesas pelo uso dos serviços pelo dispositivo. 

□ Gerenciar e configurar a segurança de aplicativos. 

□ Gerenciar e configurar a segurança do browser. 

□ Gerenciar a segurança dos dispositivos. 

□ Gerenciar os acessos a sites não permitidos. 

□ Emitir alertas de violação. 

□ Gerenciar as políticas. 

14.4.4 Processos de governança e de gestão afetados 

Do ponto de vista do CobiT 5, os principais processos que devem ser 
reforçados são: 

□ Todos os processos de governança, tais como EDM01, EDM02, 
EDM03 e EDM05 (vide Tabela 14.1). 

□ Processo APQ03 - Gerenciar a arquitetura corporativa . 

□ Processo APQ12 - Gerenciar riscos . 

□ Processo APQ13 - Gerenciar a segurança . 

□ Processo BAI09 - Gerenciar ativos . 

□ Processo BAI10 - Gerenciar a configuração . 

□ Os processos do domínio Monitorar, Avaliar e Medir (MEA), devido 
às muitas questões envolvidas de controle e compliance com requisitos 
internos e externos. 








D 


Governança de TI para Pequenas e 
Médias Empresas 


Frequentemente, em nossas salas de aula, os alunos nos questionam ar¬ 
gumentando que a maioria dos modelos de melhores práticas não se aplica a 
pequenas e médias organizações, pois há muitas barreiras para a implantação, 
até mesmo, de princípios básicos de gestáo de TL 

Para fins de entendimento e de acordo com o Cadastro de Empresas do 
IBGE (2008) 130 , pequenas e médias empresas no Brasil possuem as seguintes 
características: 

□ Pequenas empresas têm entre cinco e 99 pessoas empregadas. 

□ Médias empresas têm entre cem e 499 pessoas empregadas. 

□ Estáo concentradas no setor de serviços. 

□ Sáo os maiores empregadores no Brasil. 

Os dirigentes dessas empresas sáo, geralmente, pequenos empreendedores e 
self-made men , muitos sem uma trajetória de estudos formais e bastante intuitivos. 

Além do mais, as pequenas empresas sofrem com barreiras de acesso a cré¬ 
dito, assim como a conhecimentos e tecnologia de serviços ou de produçáo. 

O cenário da TI em pequenas e médias empresas no Brasil pode ser carac¬ 
terizado como: 

□ A infraestrutura de TI náo é complexa. 

□ Tarefas mais complexas sáo terceirizadas (tais como suporte à rede, 
desenvolvimento de sistemas e implantação de sistemas integrados 
de gestáo). 


130 Existem outras classificações de porte de empresa, tais como a Lei 9.841 de 05/10/1999, SEBRAE 
e BNDES. 
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□ Geralmente compra-se em vez de desenvolver. 

□ Há limitações de habilidades em TI dentro da empresa. 

□ A tolerância ao risco é alta. 

□ Há muito foco em relação aos custos. 

□ A estrutura de comando é simples. 

□ Existem poucos controles. 

□ O foco da informatização está nas áreas administrativas e financeiras 
das empresas e na automação de pontos de venda (no caso de empre¬ 
sas comerciais) 131 . 

□ Uso de e-mail. 

□ Eventualmente, há aplicações de B2B e B2C, através da Internet. 

O estudo de Prates & Ospina (2004) mostrou que os principais entraves 
para a informatização de pequenas e médias empresas são: a resistência dos 
funcionários pelo temor de perda de emprego e a falta de treinamento e pre¬ 
paração adequada, assim como a cultura arraigada no modelo atual utilizado 
para fazer as coisas. Entretanto, o êxito está associado ao envolvimento da 
cúpula da empresa, que é impelida a informatizar a empresa por razões de 
sobrevivência e espera, depois de implantar a informatização, benefícios como 
melhores controles e maior velocidade na tomada de decisões. 

Atualmente, com os sistemas de notas fiscais eletrônicas e SPED Fiscal, as 
empresas são forçadas a informatizar suas funções administrativas e financei¬ 
ras e também funções que têm impacto direto na contabilidade, tais como o 
controle de estoque, almoxarifado etc. 

Entendemos que um modelo de Governança de TI para pequenas e médias 
empresas deve focar nos riscos principais para a continuidade do negócio e para 
o seu crescimento, em alguns aspectos de gestão e ter como principais fatores 
críticos de sucesso a postura, as habilidades e as atitudes do responsável pela TI. 

Os aspectos de continuidade dizem respeito principalmente à disponibili¬ 
dade dos sistemas integrados de gestão e de vendas para os usuários e “donos” 
da empresa. 

Logo, os aspectos críticos, no tocante à continuidade do negócio, são: 

□ Gerenciamento da rede. 

□ Redundância dos servidores críticos. 

□ Existência de site backup. 


131 Vide Vidal et al (2005). 




Governança de TI para Pequenas e Médias Empresas 573 


□ Gerenciamento da capacidade e disponibilidade. 

□ Rotinas de backup. 

□ Guarda e armazenamento de mídias. 

□ Segurança física do data center (se for próprio da empresa). 

□ Algum tipo de segurança lógica na rede. 

□ Gerenciamento da manutenção dos recursos computacionais. 

□ Gerenciamento da configuração e inventário de recursos 
computacionais. 

□ Gerenciamento do suporte ao usuário. 

Os aspectos de crescimento dizem respeito ao aumento da abrangência da 
informatização para além das funções administrativas e financeiras, tais como 
sistemas gerenciais. 

Os aspectos críticos no tocante ao crescimento são: 

□ Planejamento das necessidades de sistemas. 

□ Planejamento da aquisição de novos sistemas e soluções de TI. 

□ Contratação de novos sistemas e serviços terceirizados. 

□ Integração dos novos sistemas com o “legado”. 

□ Testes das novas soluções. 

□ Avaliação de riscos da integração e implantação das novas soluções. 

□ Planejamento da evolução da infraestrutura tecnológica. 

Em uma pequena ou média empresa, deve haver um mínimo de gestão da 
TI, caracterizada por: 

□ Gestão do orçamento da TI. 

□ Gestão dos contratos e serviços terceirizados. 

□ Gestão dos serviços e infraestrutura de TI. 

□ Gestão dos recursos humanos. 

□ Gerenciamento do desempenho da TI. 

Entretanto, este cenário exige maiores habilidades do responsável pela TI 
da empresa, tais como: capacidade de planejamento, de entender o negócio, 
possuir habilidades técnicas de sistemas e infraestrutura, capacidade de in¬ 
duzir os “donos” do negócio a investir em TI, capacidade de saber contratar 
serviços e de gerenciar o trabalho de terceiros. 
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No contexto de pequenas e médias empresas, um modelo de Governança 
de TI deve se assemelhar a recomendações de práticas gerenciais. 

A Tabela 15.1 apresenta as principais recomendações de práticas gerenciais 
que podem ser adotadas por pequenas e médias empresas 132 . 


Prática Gerencial 

Recomendações 

Planejamento da TI 

• Entenda a contribuição que a TI possa dar ao negócio. 

• Analise como a concorrência está usando a TI. 

• Converse com os executivos para saber quais são os planos de 
crescimento da empresa. 

• Elabore uma lista de possibilidades; veja se a continuidade dos serviços 
está garantida. 

• Faça um levantamento de custos e riscos e apresente à diretoria 
as possibilidades de investimento, tanto para o crescimento, para a 
melhoria de controles ou para a melhoria das condições de continuidade 
dos serviços de TI. 

• Mostre o que o negócio vai ganhar com esses investimentos. 

• Execute ao menos uma vez por ano este processo. 

• Documente a lista de intenções e iniciativas. 

Planejamento de aquisições de 
novos sistemas e soluções de TI 

• Analise a possibilidade de comprar em vez de desenvolver internamente. 

• Avalie as soluções existentes no mercado e a credibilidade dos 
fornecedores de softwares e serviços. 

• Selecione softwares com boa base no mercado. 

• Procure conversar com usuários desses sistemas em outros clientes do 
fornecedor. 

• Avalie não somente os requisitos funcionais, mas a compatibilidade da 
arquitetura de software. 

• Avalie o custo total de propriedade da solução e a qualidade do 
fornecedor na implantação, no treinamento e na manutenção/evolução. 

• Avalie, por fim, a saúde financeira da empresa. 

• Em relação a serviços de TI, hosting, serviços de data center, veja 
também a possibilidade de terceirizar. 

Contratação de novos sistemas 
e serviços terceirizados 

• Estabeleça um processo simples para a contratação, avaliando pelo 
menos três fornecedores. 

• Estabeleça os requisitos dos serviços a serem contratados em termos de 
escopo do fornecimento, prazos, documentação a ser fornecida e formas 
de pagamento. 

• Se for contratar desenvolvimento de terceiros, elabore um roteiro mínimo 
de desenvolvimento que deverá ser seguido. 

• No caso de sistemas, envolva os usuários no processo de escolha do 
novo sistema. 


132 Baseamo-nos no CobiT Quickstart [ITGI (2007)] para elaborar as recomendações, considerando, 
entretanto, a realidade brasileira. Este modelo, apesar de estar associado à versão 4.1 do CobiT 
(anterior), ainda está disponível para download para membros da ISACA, sendo considerado uma fonte 
simplificada de extrema valia de práticas de Governança de TI para pequenas e médias empresas. 
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Prática Gerencial 

Recomendações 

Integração de novos sistemas 
com o legado 

• Avalie os riscos de continuidade e faça, juntamente com o fornecedor, 
um plano de integração e um plano de testes, estabelecendo condições 
de contingência se algo der errado. 

Testes das novas soluções 

• Solicite dos terceiros um plano de testes da nova solução e envolva os 
usuários na homologação. 

• Pense em segregar ambientes de teste e de produção. 

Avaliação de riscos da 
integração de novas soluções 

• Avalie os riscos, ou seja, o que pode dar errado, e estabeleça planos de 
contingência e ações de mitigação. 

Planejamento da evolução da 
infraestrutura tecnológica 

• Avalie o crescimento do uso dos recursos pela empresa. 

• Avalie se a capacidade atual atende ao crescimento (se não atende, 
planeje a evolução dessa infraestrutura). 

• Se o serviço for terceirizado, reúna-se com o fornecedor para fazer esse 
planejamento. 

• Sempre quando for incorporar novas soluções de sistemas, avalie a 
capacidade requerida e também se você possui esta capacidade. 

Gerenciamento da rede 

• Este serviço pode ser terceirizado. 

• Use softwares disponíveis no mercado (entretanto, você terá que adquirir 
o conhecimento para tal). 

• Uma alternativa é o body shopping para o gerenciamento da rede. 

Redundância de servidores 
críticos 

• Se você contratar serviços de data center, estabeleça as condições de 
contingência para as aplicações críticas e os níveis para recuperação de 
serviços. 

• Caso o data center seja da empresa, é imprescindível espelhar os 
servidores críticos. 

Site backup 

• Tenha um site backup para fins de contingência, de forma que os 
serviços possam ser recuperados rapidamente. 

• Caso você fizer uso de serviços de hosting, solicite ao fornecedor 
de serviços garantias de disponibilidade e avalie a capacidade do 
fornecedor de dar esta garantia. 

• Estabeleça acordos de níveis de serviços de disponibilidade dos 
principais aplicativos da empresa. 

Gerenciamento da capacidade e 
disponibilidade 

• Se o data center for seu, monitore a capacidade e a disponibilidade 
dos servidores de banco de dados e de aplicações (para tanto você 
precisará de softwares específicos). 

• Há soluções de aluguel desse tipo de software - os preços variam com o 
volume dos itens a serem monitorados. 

• Se você usa um serviço de hosting, estabeleça condições para 
esse monitoramento e combine-as com os níveis de serviços de 
disponibilidade das aplicações. 

Rotinas de backup 

• Estabeleça rotinas de backup (você pode automatizar essas rotinas 
através de software). 

• Se você usa serviços de hosting, estabeleça esse requisito em contrato 
e avalie a rotina usada pelo fornecedor. 

• As mídias de backup devem ter identificação correta. 

• As rotinas podem variar, dependendo da relevância do aplicativo. 
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Prática Gerencial 

Recomendações 

Guarda e armazenamento de 
mídias 

• Você deve guardar mídias, backups, softwares etc. em local seguro, de 
preferência em cofres, seja dentro ou fora da empresa. 

• Você pode contratar serviços para a guarda de mídias. 

Segurança física do data center 

• Se o data center for da empresa, deve ter o mínimo de condições de 
segurança física (tais como controles de entrada e saída de pessoas, 
refrigeração adequada, sistema contra incêndios). 

• 0 data center não pode estar em áreas contíguas a áreas externas de 
circulação de pessoa. 

• Deve ter um cabeamento adequado e racks com portas, assim como 
fundo falso. 

• Não use desktops como servidores. 

• Retire qualquer material inflamável da sala de computadores e não a use 
como a moxarifado para outros tipos de materiais. 

Segurança lógica 

• Tenha um antivírus atualizado. 

• Estabeleça, junto aos usuários dos sistemas, os privilégios de acesso. 

• Gerencie esses privilégios e estabeleça um acordo com o RH da empresa, 
para que ele lhe informe quando os funcionários entram e saem. 

• Tenha um sistema que possibilite o tog de acessos à rede e aos 
sistemas da empresa. 

• Tenha desktops na rede administrativa ou de produção sem leitores/ 
gravadores de CD/DVD e de dispositivos móveis de armazenamento tipo 
pen drive (você pode abrir exceções para o pessoal da diretoria, mas 
com a sua aprovação). 

• Segregue redes internas de outras redes, estabelecendo perímetros de 
segurança. 

• Se você for usar serviços de terceiros, estabeleça junto ao fornecedor as 
políticas de segurança da informação. 

Gerenciamento da manutenção 
dos recursos computacionais 

• Se você tiver uma rede de computadores significativa, contrate serviços 
de terceiros para a sua manutenção. 

• No data center, procure ter equipamentos de fornecedores de alta 
confiabilidade e estabeleça em contrato requisitos de manutenção 
preventiva e também corretiva. 

Gerenciamento da configuração 
e inventário de recursos 
computacionais 

• Faça periodicamente o inventário dos recursos (você pode usar 
softwares livres específicos para essa finalidade). 

• Não use software pirata, e sim softwares licenciados (sempre). 

• Estabeleça uma política de obsolescência dos microcomputadores, 
notebooks e outros dispositivos móveis. 

Gerenciamento do suporte aos 
usuários 

• Tenha um software para o registro de chamados de usuários. 

• Analise os chamados, verifique onde estão as maiores ocorrências de 
incidentes, avalie as causas e tome ações para reduzi-los. 

• Faça as mudanças requeridas na configuração. 

Gestão do orçamento 

• Faça anualmente um orçamento para a TI, mostrando do que cada 
negócio ou função da empresa precisa. 

• 0 orçamento da TI existe para a empresa poder funcionar. 

• Controle o orçamento. 

• Mostre para a diretoria as consequências da não aprovação do orçamento. 
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Prática Gerencial 

Recomendações 

Gestão dos contratos e serviços 
terceirizados 

• Gerencie os níveis de serviços dos terceiros. 

• No caso de serviços de desenvolvimento, estabeleça marcos de controle 
e reúna-se periodicamente com o fornecedor para avaliar o progresso 
do projeto. 

Gestão dos serviços de 
infraestrutura 

• Verifique: 

• se os controles de segurança lógica e física estão funcionando; 

• se os níveis de serviços estão sendo atendidos; 

• se as rotinas de backup e os procedimentos de manuseio das mídias 
estão sendo seguidos. 

Gerenciamento dos recursos 
humanos 

• Elabore um plano de desenvolvimento para cada funcionário, visando 
desenvolver habilidades requeridas ou novas. 

• Mantenha junto ao RH uma política de remuneração compatível com o 
mercado e faça ações para reter os talentos. 

Gestão do desempenho da TI 

• Você deve demonstrar os resultados do trabalho da TI para a diretoria 
da empresa (por exemplo, se os chamados estão sendo atendidos, se 
os incidentes estão sendo resolvidos e reduzidos em quantidade, se a 
disponibilidade está sendo atendida, se os custos estão sob controle). 

• Procure demonstrar também o que a empresa ganhou com novas 
aplicações e assim sucessivamente. 


Tabela 15.1 - Práticas gerenciais para a Governança de TI em pequenas e médias empresas 


A implantação dessas práticas gerenciais não requer um plano elaborado. 
Tais práticas podem ser adotadas passo a passo, na medida do possível. Acre¬ 
ditamos que esse conjunto de recomendações possa ser um norte para o res¬ 
ponsável pela TI. 

Entretanto, no nosso entendimento, há uma série de barreiras para a im¬ 
plantação da Governança de TI em pequenas e médias empresas, tais como: 

□ O responsável pela TI pode também executar atividades operacionais 
de desenvolvimento, de suporte ou de gestão da infraestrutura. Neste 
caso, não conseguirá interagir com a administração da empresa no 
que diz respeito às questões gerenciais, de planejamento, de gestão de 
investimentos e orçamento, de continuidade dos serviços e de mini- 
mização de riscos. 

□ A cultura da empresa pode ser bastante tolerante ao risco e desconhe¬ 
cer completamente o uso da TI para o seu crescimento e perenidade. 

□ Possibilidade de haver problemas no acesso a fundos de financiamen¬ 
to e crédito para aquisição de recursos de TI. 









578 Implantando a Governança de TI - 4 a edição 


□ Eventualmente, a ausência completa de planejamento da empresa pode 
impedir que o responsável conheça, de antemão, os requisitos do ne¬ 
gócio para planejar a expansão da infraestrutura e dos recursos de TI. 

A Tabela 15.2 apresenta ações que podem ser executadas para minimizar o 
impacto dessas barreiras. 


Barreira 

Ação Recomendada 

0 responsável pela TI também é 
operacional 

Neste caso, a ação depende muito do responsável pela TI. A 
alternativa é aproximar-se do dono da empresa e mostrar que 
a duplicação de funções é incompatível com as necessidades e 
demandas da empresa. Aqui, pode-se apelar para a questão dos 
riscos e seu impacto no negócio. 

Cultura da empresa tolerante ao risco 

Deixe claro para a diretoria da empresa o impacto que os riscos 
podem ter sobre a continuidade e o crescimento da empresa, 
mostrando-o preferencialmente em valores monetários. 

Problemas de acesso a fundos de 
financiamento 

Contrate serviços em vez de comprar. Veja a possibilidade de usar 
o cartão BNDES para aquisição de recursos computacionais. 

Ausência de planejamento na empresa 

Entenda como funciona o negócio e aproxime-se do dono. Procure 
descobrir quais são os seus planos e elabore seu plano de TI com 
base nesse entendimento, apresentando-o aos diretores para 
aprovação. 


Tabela 15.2 - Ações de mitigação das barreiras de implantação da Governança de TI 


Pode ser importante que a empresa busque apoio de entidades como o 
Sebrae, que tem vários programas e projetos para auxiliar a melhoria significa¬ 
tiva da gestão de pequenas e médias empresas em todos os setores funcionais, 
como, por exemplo, marketing , serviços, produção eTI. 










Governança de TI no Governo 


O Governo Federal Brasileiro vem desenvolvendo, desde a década de 90, o 
seu modelo de Governança de TI, que atualmente está consubstanciado em um 
conjunto de instruções normativas, resoluções e legislação específica e é formado 
por um sistema composto pelos órgãos da administração direta e indireta federal. 

A seguir este modelo é descrito em maiores detalhes. 


16.1 O MODELO DE GOVERNANÇA DE TI NO 
GOVERNO BRASILEIRO 

As ações de Governança de TI no âmbito do Governo Federal Brasileiro 
são representadas pelo Sistema de Administração de Recursos de Tecnologia 
de Informação (SISP 133 ). 

O Sistema de Administração de Recursos de Tecnologia da Informação 
(SISP) foi instituído pelo Decreto n° 1.048, de 21 de janeiro de 1994, e atua¬ 
lizado (revogado) pelo Decreto n° 7.579, de 11 de outubro de 2011, com o 
objetivo de organizar a operação, o controle, a supervisão e a coordenação dos 
recursos de informação e informática da administração direta, autárquica e 
fundacional do Poder Executivo Federal. 

São atribuições do SISP, de acordo com o Decreto n° 7.579, de 11 de ou¬ 
tubro de 2011: 

□ Assegurar ao governo federal suporte de informação adequado, dinâ¬ 
mico, confiável e eficaz. 


133 Vide informações sobre o SISP em www.planejamento.gov.br. 
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□ Facilitar aos interessados a obtenção das informações disponíveis, 
resguardados os aspectos de disponibilidade, integridade, confiden¬ 
cialidade e autenticidade, bem como restrições administrativas e li¬ 
mitações legais. 

□ Promover a integração e a articulação entre programas de governo, 
projetos e atividades, visando a definição de políticas, diretrizes e nor¬ 
mas relativas à gestão dos recursos de tecnologia da informação. 

□ Estimular o uso racional dos recursos de tecnologia da informação, 
no âmbito do Poder Executivo federal, visando a melhoria da quali¬ 
dade e da produtividade do ciclo da informação. 

□ Estimular o desenvolvimento, a padronização, a integração, a intero¬ 
perabilidade, a normalização dos serviços de produção e a dissemina¬ 
ção de informações, de forma desconcentrada e descentralizada. 

□ Propor adaptações institucionais necessárias ao aperfeiçoamento dos 
mecanismos de gestão dos recursos de tecnologia da informação. 

□ Estimular e promover a formação, o desenvolvimento e o treinamen¬ 
to dos servidores que atuam na área de tecnologia da informação. 

□ Definir a política estratégica de gestão de tecnologia da informação 
do Poder Executivo federal. 

A estrutura do SISP é formada pelos seguintes órgãos: 

□ Como Órgão Central, a Secretaria de Logística e Tecnologia da 
Informação (SLTI) do Ministério do Planejamento, Orçamento e 
Gestão. 

□ Como Órgãos Setoriais, representados por seus titulares, as unidades 
de administração dos recursos de tecnologia da informação dos Mi¬ 
nistérios e dos órgãos da Presidência da República. 

□ A Comissão de Coordenação, formada pelos representantes dos Ór¬ 
gãos Setoriais, presidida por representante do Órgão Central. 

□ Como Órgãos Seccionais, representados por seus titulares, as unida¬ 
des de administração dos recursos de tecnologia da informação das 
autarquias e fundações. 

□ Como Órgãos Correlatos, representados pelos seus titulares, as uni¬ 
dades desconcentradas e formalmente constituídas de administra¬ 
ção dos recursos de tecnologia da informação nos Órgãos Setoriais e 
Seccionais. 
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Poderão colaborar com o SISP, mediante acordos específicos com o Órgão 
Central, outras entidades do Poder Público e entidades da iniciativa privada 
interessadas no desenvolvimento de projetos de interesse comum. 

Compete à Secretaria de Logística e Tecnologia da Informação (SLTI): 

□ Orientar e administrar os processos de planejamento estratégico, de 
coordenação geral e de normalização relativos aos recursos de tecno¬ 
logia da informação abrangidos pelo SISP. 

□ Definir, elaborar, divulgar e implementar, com apoio da Comissão de 
Coordenação, as políticas, diretrizes e normas gerais relativas à gestão 
dos recursos do SISP e ao processo de compras do Governo na área 
de tecnologia da informação. 

□ Promover a elaboração de planos de formação, desenvolvimento e 
treinamento do pessoal envolvido na área de abrangência do SISP. 

□ Incentivar ações prospectivas, visando acompanhar as inovações téc¬ 
nicas da área de tecnologia da informação, de forma a atender às 
necessidades de modernização dos serviços dos órgãos e entidades 
abrangidos pelo SISP. 

□ Promover a disseminação das políticas, diretrizes, normas e informa¬ 
ções disponíveis, de interesse comum, entre os órgãos e as entidades 
abrangidos pelo SISP. 

Compete aos Órgãos Setoriais do SISP: 

□ Coordenar, planejar, articular e controlar as ações relativas aos recur¬ 
sos de tecnologia da informação, no âmbito dos respectivos Ministé¬ 
rios ou órgãos da Presidência da República. 

□ Fornecer subsídios ao Órgão Central do SISP, por intermédio da Co¬ 
missão de Coordenação, para a definição e elaboração de políticas, 
diretrizes e normas gerais relativas ao SISP. 

□ Cumprir e fazer cumprir, por meio de políticas, diretrizes, normas e 
projetos setoriais, as políticas, diretrizes e normas gerais emanadas do 
Órgão Central do SISP. 

□ Participar, como membros da Comissão de Coordenação, dos encon¬ 
tros de trabalho programados para tratar de assuntos relacionados ao 
SISP. 
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Compete à Comissão de Coordenação do SISP: 

□ Participar da elaboração e implementação das políticas, diretrizes e 
normas gerais relativas à gestão dos recursos do SISP e ao processo de 
compras do Governo na área de tecnologia da informação. 

□ Assessorar o Órgão Central do SISP no cumprimento de suas atribuições. 

□ Promover o intercâmbio de conhecimento entre seus participantes e 
homogeneizar o entendimento das políticas, diretrizes e normas ge¬ 
rais relativas ao SISP. 

□ Acompanhar e avaliar os resultados da regulamentação emanada do 
Órgão Central do SISP, e propor ajustamentos. 

Compete aos Órgãos Seccionais do SISP: 

□ Cumprir e fazer cumprir, por meio de políticas, diretrizes, normas 
e projetos seccionais, as políticas, diretrizes e normas emanadas do 
Órgão Setorial do SISP a que estão vinculados. 

□ Subsidiar o Órgão Setorial do SISP a que estão vinculados na elabo¬ 
ração de políticas, diretrizes, normas e projetos setoriais. 

□ Participar dos encontros de trabalho programados para tratar de as¬ 
suntos relacionados ao SISP. 

Compete aos Órgãos Correlatos do SISP: 

□ Subsidiar a unidade de tecnologia da informação de seu respectivo 
Órgão Setorial ou Seccional no cumprimento das políticas, diretrizes 
e normas gerais relativas ao SISP. 

□ Subsidiar a unidade de tecnologia da informação de seu respectivo 
Órgão Setorial ou Seccional na elaboração de políticas, diretrizes, 
normas e projetos setoriais ou seccionais. 

□ Participar dos encontros de trabalho programados para tratar de as¬ 
suntos relacionados ao SISP. 

Quanto à normatização dos aspectos referentes à Segurança da Informação 
no Governo Federal, a responsabilidade é do Gabinete de Segurança Institu- 
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cional da Presidência da República, através do seu Departamento de Seguran¬ 
ça da Informação e Comunicações (http://www.gsi.gov.br). 

Por fim, a fiscalização da tecnologia da informação na Administração 
Pública Federal é de responsabilidade do Tribunal de Contas da União 
(www.tcu.gov.br). 

Um dos aspectos essenciais deste modelo é a Estratégia Geral de Tecnologia 
da Informação (EGTI), elaborada pelo SLTI no âmbito do SISP. 

A EGTI traça a direção da Tecnologia da Informação, definindo o plano 
estratégico que visa promover a melhoria contínua da gestão e governança de 
TI, assim como a sustentação da infraestrutura, além de subsidiar os órgãos 
do Sistema na elaboração dos Planejamentos de Tecnologia da Informação, 
inclusive em atendimento ao que determina o Art. 3 o . da Instrução Norma¬ 
tiva (IN) SLTI/MP n° 04, de 12 de novembro de 2010 [MPOG, 2013]. 

A atual versão do EGTI 2013-2015 está alicerçada no Plano Brasil 2022 
e no Plano Plurianual (PPA) do quadriénio 2012-2015, pois valoriza a trans- 
versalidade das políticas públicas. 

O documento é um instrumento efetivo de comunicação da estratégia en¬ 
tre os Órgãos Setoriais, Seccionais, Correlatos e o Órgão Central do SISP e 
permite o acompanhamento das ações realizadas, a retroalimentação e, em 
caso de necessidade, o realinhamento da estratégia. 

A Figura 16.1 apresenta o Mapa Estratégico do SISP para o atual biênio 
2013-2015, que evidencia os objetivos estratégicos para a TI do Governo 
Federal. 

No ETGI, foi elaborado o BSC com as metas para atendimento a cada 
objetivo estratégico do Mapa Estratégico do SISP, assim como os indicadores 
e as iniciativas associadas. 

Outros instrumentos importantes para reforçar a Governança de TI nos 
órgãos setoriais e seccionais do SISP são um conjunto de instruções normati¬ 
vas, padrões e especificações geradas pela SLTI com o apoio da Comissão de 
Coordenação do SISP, relacionados a seguir: 

□ Instrução Normativa 04 da SLTI, que define requisitos para contra¬ 
tações de serviços de TI, as quais estão condicionadas à existência de 
um Plano Diretor de Tecnologia da Informação. 

□ Metodologia de gerenciamento de projetos do SISP. 
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Missão: 

Promover a melhoria da governança e da gestão de tecnologia da informação nos órgãos integrantes do 
Sistema, agregando valor às políticas e ao desenvolvimento sustentável do país. 


Figura 16.1 - Mapa estratégico do SISP 
Fonte: MPOG (2013) 


□ Guia para elaboração do PDTI do SISP. 

□ Padrões para o Governo Eletrônico como: 

A e-MAG - Modelo de Acessibilidade de Governo Eletrônico. 
A Padrões de Interoperabilidade de Governo Eletrônico. 

A e-PWG - Padrões Web em Governo Eletrônico. 

A Indicadores e Métricas para Avaliação de e-Serviços. 

A Diretrizes para criação de domínios. 

A Guia Livre - Referência de Migração para Software Livre. 


Outros instrumentos em linha com os objetivos estratégicos do SISP 
são o Plano de Capacitação do SISP e Portarias que regulam as matérias 
relativas ao provimento de cargos e gratificações no sistema, visto que a 
retenção de profissionais de TI na Administração Pública Federal é consi¬ 
derada questão estratégica, principalmente em relação ao pessoal de nível 
gerencial. 
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16.2 O papel da Secretaria de Logística e 
Tecnologia da Informação 

De acordo com o site www.planejamento.gov.br - “a Secretaria de Logís¬ 
tica e Tecnologia da Informação — SLTI — é responsável pela regulamentação 
das compras e contratações e também pelas normas relacionadas ao uso de 
Tecnologia da Informação no âmbito da Administração Pública Federal. Os 
trabalhos da SLTI têm os objetivos de ampliar a transparência e o controle 
social sobre as ações do Governo Federal. 

A SLTI tem, entre suas atribuições, a competência de planejar, coordenar, 
supervisionar e orientar, normativamente, as atividades do SISP, propondo 
políticas e diretrizes de Tecnologia da Informação no âmbito da Administra¬ 
ção Pública Federal direta, autárquica e fundacional.” 

Como vimos anteriormente, a SLTI é o órgão central do SISP. 

SLTI preside a Comissão de Coordenação do SISP e provê suporte admi¬ 
nistrativo ao seu funcionamento. 

A SLTI é responsável por coordenar a elaboração e publicação de normas e 
instruções para os integrantes do SISP. 


16.3 O papel do Tribunal de Contas da União 

O Tribunal de Contas da União tem o papel de fiscalizar a tecnologia da 
informação na Administração Pública Federal. 

Para tanto, conta, em sua estrutura, com a Secretaria de Fiscalização da 
Tecnologia da Informação (SEFTI), que tem como competência: 

□ Conduzir trabalhos específicos de fiscalização de tecnologia da 
informação. 

□ Apoiar as demais Secretarias do Tribunal, atuando em uma estrutura 
matricial de fiscalização. 

□ Elaborar e disseminar metodologias, manuais, notas técnicas e proce¬ 
dimentos para planejamento e execução de fiscalizações de tecnologia 
da informação. 

□ Realizar ações sistematizadas de relacionamento, divulgação e troca 
de conhecimentos com a sociedade, o Congresso Nacional e os Ges¬ 
tores Públicos. 
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A SEFTI coordena a realização de fiscalizações em Governança de TI, nos 
sistemas informatizados da Administração Pública Federal, nas iniciativas do 
Governo Eletrônico, na gestão dos recursos de tecnologia da informação, em 
editais de licitação, em contratos e em processos de aquisições diretas 134 . 


16.4 O papel do Departamento de Segurança 
da Informação e Comunicações do Gabinete 
de Segurança Institucional da Presidência da 
República 

O Departamento de Segurança da Informação e Comunicações (DSIC) 
é o responsável por coordenar toda a normatização desse tema no âmbito da 
Administração Pública Federal e tem como missão: 

□ Adotar as medidas necessárias e coordenar a implantação e o funcio¬ 
namento do Sistema de Segurança e Credenciamento (SISEC), de 
pessoas e empresas, no trato de assuntos, documentos e tecnologia 
sigilosos. 

□ Planejar e coordenar a execução das atividades de segurança ciberné¬ 
tica e de segurança da informação e comunicações na administração 
pública federal. 

□ Definir requisitos metodológicos para implementação da segurança 
cibernética e da segurança da informação e comunicações por órgãos 
e entidades da administração pública federal. 

□ Operacionalizar e manter centro de tratamento e resposta a inciden¬ 
tes ocorridos nas redes de computadores da administração pública 
federal. 

□ Estudar legislações correlatas e implementar as propostas sobre maté¬ 
rias relacionadas à segurança cibernética e à segurança da informação 
e comunicações. 

□ Avaliar tratados, acordos ou atos internacionais relacionados à segu¬ 
rança cibernética e à segurança da informação e comunicações. 


134 Para maiores informações sobre o trabalho da SEFTI, vide http://portal2.tcu.gov.br/portal/page/ 
portal/TCU/comunidades/tecnologia_informacao. 
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□ Coordenar a implementação de laboratório de pesquisa aplicada de 
desenvolvimento e de inovação metodológica, bem como de produ¬ 
tos, serviços e processos, no âmbito da segurança cibernética e da 
segurança da informação e comunicações. 

□ Realizar outras atividades determinadas pelo Ministro de Estado ou 
pelo Secretário-Executivo. 

O DSIC é responsável por elaborar instruções normativas e normas com¬ 
plementares 135 referentes à segurança da informação como: 

□ Diretrizes para a elaboração de Política de Segurança da Informação e Co¬ 
municações nos Órgãos e Entidades da Administração Pública Federal. 

□ Diretrizes para o processo de Gestão de Riscos de Segurança da In¬ 
formação e Comunicações (GRSIC) em órgãos e entidades da Admi¬ 
nistração Pública Federal. 

□ Diretrizes para a criação de Equipes de Tratamento e Respostas a In¬ 
cidentes em Redes Computacionais (ETIR) em órgãos e entidades da 
Administração Pública Federal. 

□ Diretrizes para Gestão de Continuidade de Negócios, nos aspectos 
relacionados à Segurança da Informação e Comunicações, em órgãos 
e entidades da Administração Pública Federal, direta e indireta. 

□ Diretrizes para Implementação de Controles de Acesso Relativos à 
Segurança da Informação e Comunicações, em órgãos e entidades da 
Administração Pública Federal, direta e indireta. 

□ Diretrizes para Gerenciamento de Incidentes em Redes Computacio¬ 
nais em órgãos e entidades da Administração Pública Federal. 

□ Diretrizes para uso de dispositivos móveis. 

□ Diretrizes para avaliação de conformidade nos aspectos relativos à 
Segurança da Informação e Comunicações (SIC) em órgãos ou 
entidades da Administração Pública Federal, direta e indireta. 

□ Diretrizes para a Gestão de Mudanças nos aspectos relativos à Segu¬ 
rança da Informação e Comunicações (SIC) em órgãos e entidades da 
Administração Pública Federal, direta e indireta. 


135 Vide a legislação referente à segurança da informação aplicável à Administração Pública Federal em 
http://dsic.planalto.gov.br/legislacaodsic. 
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□ Diretrizes para o processo de Inventário e Mapeamento de Ativos de 
Informação, para apoiar a Segurança da Informação e Comunicações 
(SIC), de órgãos e entidades da Administração Pública Federal, direta 
e indireta. 

□ Diretrizes para a utilização de tecnologias de Computação em Nu¬ 
vem, nos aspectos relacionados à Segurança da Informação e Co¬ 
municações (SIC), em órgãos e entidades da Administração Pública 
Federal, direta e indireta. 

□ Metodologia de Gestão de Segurança da Informação e Comunicações. 

□ Estabelece diretrizes de Segurança da Informação e Comunicações 
para o uso de redes sociais, em órgãos e entidades da Administração 
Pública Federal direta e indireta. 

□ Diretrizes para as Atividades de Ensino em Segurança da Informa¬ 
ção e Comunicações (SIC) em órgãos e entidades da Administração 
Pública Federal. 

□ Diretrizes para o Desenvolvimento e Obtenção de Software Segu¬ 
ro em órgãos e entidades da Administração Pública Federal, direta e 
indireta. 

□ Orientações específicas para o uso de recursos criptográficos como 
ferramentas de controle de acesso em Segurança da Informação e Co¬ 
municações, em órgãos ou entidades da Administração Pública Fede¬ 
ral, direta e indireta, dentre outras. 


16.5 Situação atual da Governança de Tl no 
Governo Federal, na visão do TCU 

Periodicamente, o TCU, através da Secretaria de Fiscalização de Tecnolo¬ 
gia da Informação, realiza levantamento sobre a situação da Governança de 
TI nas instituições federais da administração direta e indireta. Foi realizado 
um levantamento em 2007, outro em 2010 e agora o mais recente, em 2012 
[TCU (2013)]. 

Este levantamento 136 serve de base para que o os órgãos da Administração 
Pública Federal (APF) aprimorem a gestão e o uso dos recursos de TI e sua go¬ 
vernança (fazendo, consequentemente, uso mais eficiente e eficaz de recursos 


136 Vide www.tcu.gov.br para obter mais detalhes sobre os resultados do levantamento de auditoria. 
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públicos, assim como reduzindo os riscos de continuidade de serviços), além 
de fornecer os elementos necessários para que o TCU programe fiscalizações 
na Administração Pública Federal. 

A partir desse levantamento, o TCU pode gerar acórdãos e recomendações 
que são encaminhados para os órgãos da Administração Pública Federal, os 
quais devem implementar as recomendações dentro de determinados prazos 
estipulados. Os Acórdãos do TCU também podem ser transformados em Ins¬ 
truções Normativas e legislação específica que devem ser seguidas pela Admi¬ 
nistração Pública Federal. 

Os temas tratados nesse levantamento, que contaram com respostas de 337 
órgãos da Administração Pública Federal e que geraram um índice de maturi¬ 
dade de governança, foram: 

□ Estrutura de governança de TI. 

□ Desempenho institucional na gestão e uso da TI. 

□ Desenvolvimento interno de gestores de TI. 

□ Auditoria de TI. 

□ Planejamento estratégico e institucional de TI. 

□ Priorização das ações e gastos de TI. 

□ Estrutura de pessoal de TI. 

□ Segurança da informação. 

□ Processo de software. 

□ Processo de gerenciamento de projetos. 

□ Gestão de serviços de TI. 

□ Processo de contratação de TI. 

□ Gestão de contratos de TI. 

□ Gestão corporativa e governança de TI. 

As principais conclusões finais do levantamento foram: 

□ Houve uma melhora substancial no tocante à estrutura de governan¬ 
ça de TI em termos de responsabilização pelas políticas de TI, de¬ 
signação de um comitê de TI, designação de um comitê de TI com 
representantes das áreas de negócio e monitoramento do comitê de 
TI. Neste último item, porém, somente 42% dos órgãos fazem este 
monitoramento. 
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□ Houve uma melhora no tocante ao desempenho institucional na ges¬ 
tão e no uso da TI contemplando: estabelecimento de objetivos de 
desempenho de TI, estabelecimento de indicadores de TI e acompa¬ 
nhamento dos indicadores de benefícios dos principais sistemas de 
informação. Entretanto, ainda há muito espaço para melhorias, pois 
somente 37% dos órgãos estabelecem indicadores de TI e 23% acom¬ 
panham os indicadores. 

□ No tocante ao desenvolvimento interno de gestores de TI a melhoria 
foi pequena; entretanto, 73% dos órgãos preenchem duas funções 
gerenciais com pessoas do próprio cargo, a dependência de gestores 
externos ao órgão caiu de 22% para 19%; em 85% dos órgãos os ges¬ 
tores são escolhidos pela competência e 51% dos órgãos têm plano de 
capacitação para gestores de TI. 

□ No tocante à auditoria de TI, 54% dos órgãos não realizaram auditoria 
de TI nem em 2010 e 2011, 13% realizaram auditoria da governan¬ 
ça de TI, 18% realizaram auditoria em sistemas de informação, 19% 
auditoria em segurança da informação, 33% auditoria em contratos 
de TI e 8% auditoria de dados. De acordo com o TCU, esse resultado 
talvez seja decorrência da não existência de estrutura de auditoria de 
TI nos órgãos e também da falta de profissionais de auditoria. 

□ No tocante ao planejamento estratégico institucional e de TI, os re¬ 
sultados foram: 85% dos órgãos têm planejamento estratégico insti¬ 
tucional, 78% têm planejamento estratégico de TI e 54% têm plano 
diretor de TI. 

□ Quanto à priorização de ações e gastos de TI, em grande parte a alta 
administração toma as decisões relativas a gastos em TI com o apoio da 
área de tecnologia da informação (cerca de 46%) e em 26% dos casos 
as decisões são tomadas pela alta administração com o apoio do comitê 
de TI. 

□ Quanto à estrutura de pessoal de TI, 77% possui carreira de TI, e a 
dependência de pessoal externo caiu de 49% para 40%. 

□ Quanto à segurança da informação, 24% dos órgãos têm inventário 
de ativos de informação, 17% têm classificação da informação, 10% 
têm análise de riscos, 16% fazem gestão de incidentes, 51% desig¬ 
naram pessoal para atividades de segurança da informação e 45% 
possuem política de segurança da informação. 
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□ Quanto ao processo de software, 40% dos órgãos encontram-se nos es¬ 
tágios iniciais de maturidade, 34% estão no estágio gerenciado, 20% no 
estágio definido e 6% nos estágios mais avançados. Comparativamente 
ao levantamento do ano de 2010, houve um aumento da maturidade. 

□ Em relação ao processo de gerenciamento de projetos, 17% dos 
órgãos não praticam gerenciamento de projetos, 41% não adotam 
padrão interno ou de mercado, 27% adotam padrão interno ou de 
mercado, 5% acompanham e medem o processo e 10% melhoraram 
o processo. Houve uma melhoria no uso de padrões internos ou de 
mercado. 

□ Em relação à gestão de serviços, houve uma melhoria generalizada 
em práticas considerando gestão financeira (22%), gestão de níveis 
de serviços (24%), gestão de disponibilidade (21%), gestão de capa¬ 
cidade (15%), gestão de continuidade dos serviços (17%), gestão de 
mudanças (23%), gestão de configuração e ativos (27%), gestão de 
liberação e implantação (15%), gestão de incidentes (41%) e gestão 
de problemas (28%). 

□ Quanto ao processo de contratação de TI, 81% dos órgãos fazem 
estudos técnicos de viabilidade antes da contratação, 49% explicitam 
os indicadores de benefícios para o negócio da contratação e 81% 
usam esses benefícios para prorrogarem os contratos. 

□ A gestão de contratos de TI caiu de 34% para 30% nos órgãos onde 
há grandes variações de procedimentos adotados para contratação, 
em 39% as boas práticas são aplicadas e disseminadas, em 23% o 
processo de gestão de contratos é formalizado, em 5% o processo é 
medido e controlado e em 3% ele é melhorado continuamente. 

No tocante à Gestão Corporativa e Governança de TI as seguintes dimen¬ 
sões foram avaliadas: 

□ Liderança da alta administração. 

□ Controle de gestão em estratégias e planos. 

□ Controles de gestão em informação e conhecimento. 

□ Controle de gestão de pessoas. 

□ Controles de gestão de processos. 
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□ Resultados de gestão e de governança de TI para os cidadãos e para a 
sociedade. 

As organizações avaliadas são categorizadas, para cada dimensão, em capa¬ 
cidade de governança em termos de inicial, intermediária e aprimorada. 

O resultado da última avaliação em 286 organizações pode ser apreciado 
na Tabela 16.1 a seguir. 


Dimensão 

Resultado 

Liderança da alta administração 

49% das organizações estão no estágio inicial, 36% 
no intermediário e 15% no aprimorado. 

Controle de gestão em estratégias e planos 

28% encontram-se no inicial, 34% no intermediário e 
38% no aprimorado. 

Controles de gestão em informação e conhecimento 

45% encontram-se no inicial, 28% no intermediário e 
27% no aprimorado. 

Controle de gestão de pessoas 

20% encontram-se no inicial, 36% no intermediário e 
44% no aprimorado. 

Controles de gestão de processos 

76% encontram-se no estágio inicial, 20% no 
intermediário e somente 4% no aprimorado. 

Resultados de gestão e de governança de TI para os 
cidadãos e para a sociedade. 

35% estão no estágio inicial, 40% no estágio 
intermediário e 25% no estágio aprimorado. 


Tabela 16.1 - Resultados da avaliação de governança de TI 


Por fim, se você desejar se aprofundar no assunto de Governança de TI no 
Governo, não deixe de ler o excelente trabalho de Cepik & Canabarro (2010). 


16.6 Governança de TI no Judiciário 
Brasileiro 

A Governança de TI no Judiciário Brasileiro é capitaneada pelo Conselho 
Nacional de Justiça (CNJ), um órgão voltado à reformulação de quadros e 
meios no Judiciário, sobretudo no que diz respeito ao controle e à transpa¬ 
rência administrativa e processual. O CNJ foi instituído em obediência ao 
determinado na Constituição Federal, nos termos do art. 103-B. 

Criado em 31 de dezembro de 2004 e instalado em 14 de junho de 2005, 
o CNJ é um órgão do Poder Judiciário com sede em Brasília/DF e atuação 
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em todo o território nacional que visa, mediante ações de planejamento, a co¬ 
ordenação, o controle administrativo e o aperfeiçoamento do serviço público 
na prestação da Justiça. 

No contexto do CNJ, foi criada uma Comissão Permanente de Tecnologia 
da Informação e Infraestrutura, composta por três ministros, de acordo com 
a Portaria 604, de 07 de agosto de 2009. 

Através da Portaria 222, de 03 de dezembro de 2010, foi criado o Comitê 
Nacional de Gestão da Tecnologia da Informação e Comunicação do Poder 
Judiciário. 

Este Comitê é formado por representantes dos vários Tribunais e instâncias 
da Justiça Federal, Estadual e Ministério Público. 

As atribuições do Comitê são: 

□ Auxiliar a Comissão Permanente de Tecnologia da Informação e 
Infraestrutura. 

□ Propor ao CNJ critérios para orientar a aquisição de bens e serviços 
alusivos à área de tecnologia da informação do Poder Judiciário. 

□ Propor política de segurança da informação. 

□ Definir modelo de gestão da qualidade do software. 

□ Estabelecer padrões de interoperabilidade entre os sistemas informa¬ 
tizados do Poder Judiciário. 

□ Incentivar o desenvolvimento e o aperfeiçoamento do processo ele¬ 
trônico judicial e administrativo pelos órgãos do Poder Judiciário. 

□ Planejar a capacitação de colaboradores, servidores e magistrados na 
área de tecnologia da informação. 

□ Identificar tecnologias de interesse do Poder Judiciário e buscar par¬ 
cerias com órgãos e entes públicos e privados. 

□ Prestar os subsídios técnicos requisitados pelo Conselho Nacional de 
Justiça. 

Alguns marcos que têm impacto no processo da Governança de TI no Ju¬ 
diciário são representados pelos seguintes instrumentos: 

□ Resolução N°. 70, de 18 de março de 2009, do CNJ, que dispõe so¬ 
bre o planejamento estratégico no âmbito do Poder Judiciário. 

□ Resolução N°. 90, de 29 de setembro de 2009, do CNJ, que dispõe 
sobre os requisitos de nivelamento no âmbito do Poder Judiciário em 
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termos de quadro de pessoal, padronização de sistemas, contratação de 
serviços, infraestrutura de TIC, a necessidade por elaborar um Plano 
Estratégico de TI e um Plano Diretor de Tecnologia da Informação etc. 

□ Resolução N°. 99, de 24 de dezembro de 2009, do CNJ, que institui 
o planejamento estratégico de tecnologia da informação e comunica¬ 
ção no âmbito do Poder Judiciário. Esta resolução define a missão, 
a visão e os valores para a tecnologia da informação e comunicação 
do Judiciário, assim como os objetivos e as metas a serem alcançados. 
Anexo a essa resolução encontra-se o Plano Estratégico de TIC para 
o Poder Judiciário, conforme mostra a Figura 16.2 a seguir, a qual 
detalha objetivos, metas e indicadores correspondentes. 
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MISSÃO: prover soluções tecnológicas efetivas 
para que o Judiciário cumpra sua função 
institucional 


Visão 

Ser reconhecido pela qualidade de 
seus serviços e soluções de TIC 


Eficiência Operacional 


Primar pela 
satisfação do 
cliente de TIC 


Alinhamento e Integração 


Promover a integração e a 
troca de experiência de TIC 
entre os Tribunais (nacional e 
_ internacional) _ 


Acesso ao Sistema de Justiça 

Facilitar o acesso à Justiça, 
promovendo a capilaridade 
dos sistemas e serviços 


Responsabilidade Social 
Promover a cidadania, 
permitindo que os sistemas e 
serviços estejam disponíveis a 
todos os cidadãos 


Atuação Institucional 


Aprimorar a comunicação com 


Melhorar a imagem de TIC do 

públicos externos e internos 


Judiciário 


Gestão de Pessoas 


Desenvolver 

competências 

gerenciais 


Infraestrutura e Tecnologia 


Garantir a 


Garantir a 

infraestrutura de TIC 


disponibilidade de 

apropriada às 


sistemas de TIC 

atividades judiciais e 


essenciais ao 

administrativas 


Judiciário 


Desenvolver 
sistemas de TIC 
interoperáveis e 
portáveis 


Promover a 
segurança da 
informação 


Prover 

documentação de 
sistemas 


Orçamento 


Garantir a gestão e 
a execução dos 
recursos 
orçamentários de 
TIC 


Figura 16.2 - Mapa estratégico de TIC do Poder Judiciário 
Fonte: CNJ (2009a) 


Outro aspecto a salientar nesse modelo de Governança de TI é que, 
anualmente, são realizadas pesquisas para conhecer o estado atual da Gover¬ 
nança de TI nos órgãos do Poder Judiciário. 
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Essas pesquisas municiam a Comissão Permanente de Tecnologia da In¬ 
formação e Infraestrutura e o Comitê Nacional de Gestão da Tecnologia da 
Informação e Comunicação com informações para a avaliação, definição e 
proposição de políticas, realimentação do status das iniciativas estratégicas e 
subsídios para o novo ciclo de planejamento anual. 

Como peças de Governança de TI, no âmbito do Comitê Nacional de 
TIC, são aprovadas e expedidas Diretrizes de Segurança da Informação, o 
modelo de interoperabilidade, questionários de TIC periódicos para levantar 
a situação da Governança de TI nos órgãos do judiciário, implantação de sis¬ 
temas e assim sucessivamente. 




Como Implanta r a Governança de TI 


A implantação da Governança de TI em uma organização é um empreen¬ 
dimento de longo prazo. Na realidade, é um programa. 

Sua forma de implantação dependerá principalmente do contexto de mer¬ 
cado e da cultura de cada organização. 

Alguns fatores de contexto que devem ser analisados quanto ao foco do 
programa de Governança de TI são: 

□ Setores com maior regulamentação externa e de capital aberto (com 
ações negociadas na Bolsa de Valores) tendem a valorizar uma maior 
previsibilidade em processos e a transparência na prestação de contas. 
Possuem uma governança corporativa mais madura e que, portan¬ 
to, pode influenciar na necessidade de implantar a governança de TI 
(ex.: bancos, seguros, energia, telecom). 

□ Setores altamente competitivos e pouco regulados tendem a dar me¬ 
nos valor a processos estruturados, a não ser os relativos ao controle 
financeiro e da rentabilidade (ex.: empresas de serviços, de consumo 
de massa, varejo, bebidas etc.). 

□ Empresas de capital aberto, de uma forma geral, requerem uma boa 
Governança Corporativa, o que pode influenciar positivamente na 
implantação da Governança de TI. 

□ Empresas que têm processos produtivos complexos, integrados e/ 
ou trabalham com alta tecnologia, que podem ser fonte de riscos ao 
meio ambiente e à vida humana, também são propensas a valorizar 
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procedimentos (ex.: fabricantes de aviões, petróleo e gás, automobi¬ 
lística etc.). 

□ O estágio em que a organização se encontra ou a maturidade do 
mercado podem influenciar a adoçáo da Governança de TI. Por 
exemplo, em mercados ainda em fase de crescimento é muito pro¬ 
vável que a empresa náo tenha ainda normas, procedimentos e re¬ 
gras claras, e que o objetivo seja atender à demanda do mercado, 
prioritariamente. 

□ Nas organizações industriais em mercados mais maduros, a auto¬ 
mação industrial é valorizada, mas geralmente pertence à área in¬ 
dustrial e náo à TI. Esse tipo de empresa usa Sistemas Integrados 
de Gestão, e nelas o foco da TI está eminentemente no suporte e 
na garantia da continuidade desses sistemas. É bem provável que 
o foco da Governança seja mais o gerenciamento de serviços e a 
continuidade. 

Os contextos de mercado e competitivo de uma organização, sua histó¬ 
ria, origem de capital etc. criam diferentes culturas organizacionais. Exis¬ 
tem culturas que valorizam a inovação, outras a obtenção de resultados, 
outras a hierarquia e o controle e ainda outras são mais voltadas para 
pessoas. 

Essas variáveis influenciarão o “desenho” e o foco da Governança de TI de 
cada empresa, assim como a forma de implementá-la. 


17.1 Roteiro de implantação da Governança 
DE TI 

Apresentamos a seguir um roteiro genérico para a implantação da Gover¬ 
nança de TI, ilustrado na Figura 17.1. 
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Figura 17.1 - Roteiro proposto para a implantação de um programa de Governança de TI 


1. Sensibilizar a alta direçáo da organização quanto à necessidade de 

implantar a Governança de TI e obter patrocínio: 

Um programa de Governança de TI não acontece se não tiver patrocí¬ 
nio da alta administração da organização. Portanto, a primeira coisa a fazer é 
sensibilizá-la. 

Para tanto, podem ser utilizados vários instrumentos, tais como: 

□ Trazer palestrantes para falar sobre os resultados da Governança de TI 
em empresas similares ou outras empresas. 

□ Fazer visitas em outras empresas, junto com o superior imediato da 
TI da organização. 

□ Fornecer acesso da alta administração a pesquisas e testemunhos de 
outros profissionais executivos que implantaram ou estão implantan¬ 
do a Governança de TI. 
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□ Mostrar os riscos que a organização corre se determinadas ações que 
garantem a continuidade do negócio não forem implantadas. 

□ Mostrar a vulnerabilidade atual a incidentes de segurança da informação. 

□ Tentar mostrar benefícios monetários já obtidos com a implantação 
de projetos ou programas de Governança de TI. 

□ Obter acesso a relatórios de auditoria interna e externa ou do pessoal 
de gestão de riscos, de forma a subsidiar a demonstração de urgência 
para a implantação de boas práticas de gerenciamento de TI e de 
Governança de TI. 

Logo, para você, como CIO ou responsável pela TI, ter acesso às pessoas 
da alta administração é uma condição básica. 


2. Definir o foco do programa de Governança de TI: 

O foco do programa de Governança de TI dependerá de vários fatores, 
conforme falamos anteriormente. Esse foco pode ser obtido a partir da análise 
estratégica da organização (vide item 3.2.2.1 deste livro). 

A análise estratégica do negócio identifica os requisitos e fatores críticos de 
sucesso que afetam a TI e que revelam as prioridades de foco da Governança 
de TI. Vejamos alguns exemplos: 

□ Se o mais importante para o negócio é manter a continuidade, en¬ 
tão o foco inicial do programa de Governança poderá ser a segurança 
da informação, assim como os processos e ambientes para manter a 
continuidade. 

□ Se o mais importante for o time-to-market, é possível que o foco seja 
estruturar a gestão da demanda e do portfólio, a gestão de projetos e 
serviços e também o processo de entrega e qualidade. 

□ Se a filosofia de gestão da organização determina que grande parte do 
trabalho seja contratada de terceiros, então é necessário ter processos 
de gerenciamento de sourcing. 

Portanto, a análise estratégica do negócio poderá ajudá-lo a definir o foco 
inicial do programa de Governança de TI. 
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3. Definir os papéis e a estrutura da Governança de TI, assim como seu 

relacionamento com os interessados relevantes (alta administração, área de 

auditoria, compliance e riscos, desenvolvimento, suporte, infraestrutura 

tecnológica, segurança da informação etc.): 

Aqui você deve definir se vai criar uma área específica de Governança de 
TI, se as responsabilidades estarão compartilhadas pelos executivos de TI, se 
serão atribuídas a uma pessoa ou a um grupo de pessoas, entre outras possi¬ 
bilidades estruturais. 

Essa definição de papéis é de suma importância, pois, na realidade, a Go¬ 
vernança de TI é de responsabilidade de todos. Quem implanta os processos, 
na verdade, é o pessoal de ponta (desenvolvimento, operações, serviços etc.). 
Então, essa responsabilidade não pode estar segregada a um grupo específico. 

Outro aspecto a considerar é a atribuição das responsabilidades quanto aos 
direitos decisórios em relação à TI. 


4. Estruturar preliminarmente o programa de Governança de TI: 

Aqui você deve escolher o Gerente do Programa de Governança de TI e 
definir seu escopo básico (vide Capítulo 9, que fala sobre o modelo PMI de 
gerenciamento de programas). 


5. Implantar a estrutura e as responsabilidades pela Governança de TI: 

Nesta etapa do roteiro, você deve se estruturar com os recursos mínimos para 
começar a jornada, assim como definir políticas e comunicar a todos os inte¬ 
ressados relevantes acerca do programa e de suas políticas e responsabilidades. 


6. Estabelecer os direitos decisórios: 


Instituir, com o apoio da alta administração, o modelo de direitos decisó¬ 
rios, em termos de quem decide sobre o quê em relação à TI, quem define 
prioridades, quem aprova investimentos, de quem é o orçamento (da TI ou 
do negócio), como os serviços serão “cobrados” etc. 
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NOTA: aqui ainda náo estão sendo implantados os Comitês de Investimen¬ 
tos ou de Projeto. 


7. Realizar avaliação dos processos-foco do programa de Governança 

de TI: 


Nesta etapa você irá avaliar, com base nas melhores práticas (analisadas 
neste livro), o estágio atual das práticas correntes que seráo foco do seu pro¬ 
grama de Governança de TI. 

O objetivo é identificar, com base na análise estratégica do negócio, quais 
sáo as ações urgentíssimas a serem tomadas (que váo identificar os ganhos rá¬ 
pidos), quais seráo as ações de médio prazo e quais ações poderáo esperar mais 
um pouco. 

Para tornar a sua avaliação mais emocionante, você poderá realizar uma 
pesquisa sobre a percepção dos usuários e da alta administração sobre a área 
de TI, em termos de qualidade e atendimento ao negócio. 

Muitas vezes essas percepções não condizem com a realidade, mas mesmo 
assim você precisará trabalhar para mudá-las. 

A avaliação de processos, estruturas e meios, enfim, vai ajudá-lo a identi¬ 
ficar a quais metas e objetivos a área de TI deve atender e os riscos que a TI 
proporciona para o negócio. 


8. Estabelecer metas e indicadores de progresso e de resultado para o 

programa de Governança de TI: 

Nesta etapa, com base nos resultados da avaliação, você deverá definir as 
suas metas. 

Por exemplo, se um processo crítico de TI estiver com um nível de ma¬ 
turidade aquém do necessário, então você deverá estabelecer qual nível de 
maturidade deseja alcançar e as ações que devem ser tomadas para atingir 
esse nível. 

Outras metas e indicadores também devem ser estabelecidos. Por exemplo, 
suponha que você precisa melhorar a entrega de projetos no prazo. De quan- 
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do seria esta melhoria? De 60% para 80%? A mesma abordagem servirá para 
o índice de disponibilidade de aplicações e de serviços de infraestrutura, entre 
outras medições. Entretanto, você precisa saber qual é o seu nível de desem¬ 
penho atual para que consiga estabelecer as metas. 

Ao estabelecer as metas, você precisará se preocupar com os custos dessas 
melhorias e provavelmente terá que elaborar um orçamento para ser aprovado 
quando ocorrer a apresentação do programa de Governança de TI para a alta 
administração. 


9. Estabelecer um roadmap de implantação, considerando ações de 

curto, médio e longo prazos: 

Agora que você já sabe o que fazer, precisa definir a sequência, as 
interdependências e o horizonte temporal em que as melhorias e os novos 
processos devem ser implantados, assim como quais benefícios e capacitações 
seráo alcançados. 

Por exemplo, na implantação de práticas de gerenciamento de serviços, 
uma sequência provável seria: começar pela estruturação da Central de 
Serviços, gerenciamento de incidentes e problemas, juntamente com a ges- 
táo de configuração. Logo depois, implantar a gestáo de mudanças e, em 
seguida, o gerenciamento de capacidade e disponibilidade. Por fim, pode 
ser implantado o processo de gerenciamento da continuidade dos serviços 
de TI. 


10. Elaborar o Plano do Programa de Governança de TI: 

De posse do roadmap , você já terá uma ideia de quais projetos iráo compor 
o seu programa. A elaboração do plano do seu programa deverá considerar: 

□ O escopo do programa, ou seja, a lista de processos, estruturas e ações 
de TI a serem implementados. 

□ A sequência de implantação dos processos, considerando as prece¬ 
dências técnicas requeridas. 

□ A linha de tempo prevista para a implantação dos processos. 
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□ O plano de recursos estimado para o programa. 

□ Os serviços a serem adquiridos. 

□ O orçamento estimado para o programa e para cada um dos pro¬ 
jetos. 

□ Os benefícios esperados a serem atingidos, à medida que os processos 
forem sendo implantados. 

□ Como o programa será gerenciado. 

□ A estrutura de gestão do programa, assim como a matriz de respon¬ 
sabilidades. 

□ Os riscos do programa. 

□ A estratégia de gerenciamento da mudança para o programa. 

□ O plano de comunicação do programa. 

□ Os critérios de qualidade a serem seguidos pelos projetos. 

□ As métricas de progresso a serem consideradas pelos projetos compo¬ 
nentes do programa. 

□ Os pontos de controle do programa. 


11. Definir parcerias com as áreas de auditoria interna e externa, riscos 

e compliance: 

Por incrível que pareça, as áreas de auditoria, riscos e compliance , bem como 
a auditoria externa, são os grandes aliados da TI na jornada da Governança 
de TI, pois têm acesso à alta administração, principalmente em organizações 
com Governança Corporativa mais madura. 

Essa parceria é importante, pois através das auditorias e da área de riscos 
é possível enxergar as maiores vulnerabilidades da TI para o negócio, pelo 
olhar dos acionistas. 

Esse tipo de informação é muito importante, não só no início do progra¬ 
ma, mas também durante o seu curso, pois vai mostrando o progresso e os 
resultados das ações (se elas estão sendo realmente efetivas), do ponto de vista 
de compliance e dos riscos operacionais. 
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12. Aprovar o programa de Governança de TI; 

Para que você possa alocar recursos, contratar ferramentas e consultorias, 
treinar o pessoal, alocar recursos humanos etc., você precisará de recursos 
financeiros/ orçamentários. 

A aprovação do programa de Governança de TI pela alta administra¬ 
ção fornece a autorização para que o orçamento previsto e aprovado seja 
executado. 


13. Elaborar o plano de gerenciamento da mudança da cultura 

organizacional de TI: 

Nenhuma transformação ou resultado é alcançado se você náo mudar a 
cultura atual para uma nova cultura, de forma a dar um suporte consistente 
para os seus objetivos. 

Grande parte dos fracassos em implantação de inovações deve-se ao fato 
de que a transição de um estado atual para o futuro não é adequadamente 
gerenciada. 

A cultura de uma organização é formada pelo comportamento coletivo das 
pessoas mais um conjunto de símbolos, sistemas e processos. 

O comportamento individual de cada pessoa é fruto de suas crenças 
e dos valores. Portanto, para que uma mudança seja adotada de fato, é 
necessário começar pela mudança das crenças e dos valores das pessoas, 
de forma que seu comportamento mude, influenciando o comportamento 
coletivo. Adicionalmente e em paralelo, devemos alterar os símbolos, sis¬ 
temas e processos. 

Alguns exemplos de símbolos da cultura são: o tamanho do escritório do 
chefe, os carros da diretoria, frases do tipo “aqui trabalhamos desse jeito” etc. 

É óbvio que a mudança começa pela liderança da organização, de forma 
que a simbologia, os sistemas e os processos mudem de forma congruente 
com os objetivos da mudança. 

As figuras 17.2 e 17.3 procuram resumir essa questão. 
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CULTURA ATUAL 



RESULTADOS ATUAIS 



CULTURA DESEJADA 


RESULTADOS DESEJADOS 


Figura 17.2 - Transição da cultura 
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Figura 17.3 - Mudança através do comportamento individual 
Adaptado de Taylor (2005) 
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A Figura 17.4 mostra os principais elementos requeridos para uma mudan¬ 
ça consistente. 



Mudança 

Consistente 


Desconfiança 


Mudança 

Lenta 


Frustração 


Figura 17.4 - Elementos da mudança cultural 137 


Por fim, um plano de gerenciamento da mudança deve contemplar, no 
mínimo: 

□ Avaliação da cultura atual e a definição da cultura desejada. 

□ Avaliação dos gaps entre a cultura atual e a desejada. 

□ Identificação das ações e iniciativas para eliminar os gaps , tais 
como o plano de comunicação, mudanças da simbologia ou de 
mensagens culturais, mudanças em sistemas e processos voltados 
a pessoas. 

□ Criação do grupo de gerenciamento da mudança, composto pelos 
líderes da TI da organização. 


137 Esta mesma figura aparece no final do Capítulo 3 deste livro, que detalha o conceito de gestão de 
mudança organizacional. 
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□ Um plano de comunicação explicando do que se trata a mudança, 
a visão (onde se quer chegar), o porquê da mudança, os benefícios 
para a organização, o programa de Governança de TI, os projetos e 
as responsabilidades, os comitês e suas finalidades. Essa comunicação 
pode ser feita através de reuniões e palestras e contar com um portal 
na intranet da organização. 

□ Sistema de recompensas e reconhecimento, tendo em vista que mui¬ 
tas vezes há pessoas que perdem algo na mudança. Se for de interesse 
da organização manter essas pessoas, deverá estabelecer algum tipo de 
recompensa, monetária ou não. Além do mais, as pessoas gostam de 
verificar se o seu esforço teve resultado. 

□ Programa de capacitação, pois as pessoas precisarão ter a competên¬ 
cia requerida para lidar com os novos processos e sistemas que serão 
implantados durante a fase de transição. 

□ Programa de desenvolvimento de lideranças e coaching , com o obje¬ 
tivo de mudar valores e crenças dos líderes da TI, de forma que deem 
o exemplo para os seus liderados. 

□ Estabelecimento de metas de resultados pela mudança atreladas, se 
possível, à remuneração variável. 

□ Os recursos necessários para implantar os mecanismos da mudança, 
juntamente com um orçamento. 

□ Sistemática de suporte técnico para as pessoas poderem realizar o tra¬ 
balho após a aprendizagem teórica ou o programa de formação. 

□ Um plano de ação com cronograma, responsabilidades e esquema de 
gerenciamento do processo de mudança. 

Assim, o plano de gerenciamento da mudança cultural é um suporte valio¬ 
so para o programa de Governança de TI. 


14. Elaborar o plano dos projetos de implantação da Governança de TI; 

Para cada ação ou iniciativa requerida para a implantação da Governança 
de TI dentro do foco escolhido, deverá ser elaborado um plano de proje¬ 
to. Aqui você poderá usar os ensinamentos do Project Management Body of 
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Knowledge (PMBOK), do PMI, que estabelece o conteúdo do Plano de Ge¬ 
renciamento do Projeto. 


15. Implantar as acóes do plano de gerenciamento da mudança da cultura 

organizacional de TI: 

Em paralelo ao desenvolvimento dos projetos específicos de Governança 
de TI, o seu plano de gerenciamento de mudança já deverá estar em marcha. 
Imaginamos que, uma vez que você já tenha o roadmap da Governança de TI, 
você já possa dar início à execução do seu plano de gerenciamento da mudança 
cultural. 


16. Executar os projetos de implantação da Governança de TI: 

Aqui você deve seguir também os ensinamentos do PMBOK, visando o 
gerenciamento da execução dos projetos específicos, relativos à Governança 
de TI. 


17. Monitorar a execução dos projetos de implantação da Governança 

de TI: 


A Governança de TI deverá monitorar os projetos específicos de Gover¬ 
nança de TI, visto que as responsabilidades pela implantação sáo das demais 
áreas de TI. Por meio do monitoramento, você deverá saber sobre o andamen¬ 
to do progresso, a qualidade dos entregáveis, a situaçáo dos riscos, o nível de 
adoção, as mudanças que ocorreram. E muito importante que sua organiza¬ 
ção tenha uma metodologia de gerenciamento de projetos. 


18. Avaliar os resultados dos projetos de implantação da Governança de TI: 

À medida que os projetos forem entregues, você deverá avaliar se os resul¬ 
tados foram ou estáo sendo alcançados. 
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19. Comunicar o valor gerado pela TI ao negócio: 

Geralmente os executivos de negócios percebem o valor da TI para o ne¬ 
gócio da seguinte forma: 

□ Os projetos de sistemas e soluções devem ser entregues no prazo e 
com os requisitos acordados. 

□ Os projetos de sistemas sáo entregues dentro do time-to-market do 
negócio. 

□ As aplicações e os serviços devem estar disponíveis de acordo com os 
ciclos operacionais do negócio e conforme os níveis de serviços acor¬ 
dados com os gestores do negócio. 

□ ATI deve ter capacidade de atender à expansão do negócio ou de suas 
transações rapidamente, visando atender ao time-to-market requerido. 

□ O negócio quer uma rápida resolução de incidentes que afetam a sua 
operação. 

□ O negócio quer uma rápida recuperação de serviços, quando um in¬ 
cidente afeta a sua operação. 

□ O negócio quer que a TI contribua com inovações tecnológicas e de 
processo para a sua operação. 

□ O negócio deseja que as plataformas de aplicações, software e de 
infraestrutura sejam flexíveis para acompanhar o crescimento do 
negócio. 

Portanto, o programa de Governança de TI deverá avaliar, para cada pro¬ 
jeto, qual(is) dos requisitos de sucesso, do ponto de vista do negócio, será(ão) 
atendido (s). Os resultados deverão ser medidos e comunicados à alta admi¬ 
nistração e aos patrocinadores. 

Os ganhos podem ser comunicados pelo portal do programa de Governan¬ 
ça de TI, que apoia o plano de gerenciamento da mudança. 


20. Revisar e evoluir o Programa de Governança de TI; 

À medida que os projetos forem sendo entregues, a cultura começará a 
mudar, os resultados começarão a aparecer e você deverá planejar a evolução 
do programa de Governança de TI. 
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A evolução pode ser uma melhoria no que já foi implantado ou pode ser 
o atendimento a um novo foco, a partir de uma nova análise estratégica da 
organização. 


17.2 Fatores críticos de sucesso para a 

IMPLANTAÇÃO DA GOVERNANÇA DE TI 

Para que a implantação de um programa de Governança de TI seja bem- 
-sucedida, alguns requisitos devem ser atendidos: 

□ Liderança para a mudança: nenhuma mudança organizacional 
ocorre sem que tenha um executivo patrocinador que assuma a sua 
liderança e garanta os fundos necessários para o empreendimento. 
Um programa de Governança de TI que não possui um patroci¬ 
nador da alta direção da empresa pode ter sérios problemas na sua 
implementação. 

□ Envolvimento dos executivos da organização: além do executivo 
patrocinador, responsável por liderar a mudança, o programa de Go¬ 
vernança de TI também necessita do envolvimento dos demais exe¬ 
cutivos da organização. O motivo é muito simples: a implantação de 
novos processos de TI pode alterar a forma como as demais áreas da 
empresa são atendidas pela TI. Geralmente, os executivos de outras 
áreas não entendem que a TI também precisa de instrumentos para a 
gestão de seus serviços. 

□ Atacar as principais vulnerabilidades: as principais vulnerabili¬ 
dades devem ser priorizadas no programa de Governança de TI, 
de forma que seja possível obter resultados a curto prazo. Isso 
é extremamente importante para o sucesso do empreendimen¬ 
to. Esses resultados sempre devem ser comparados aos resultados 
anteriores, para que a melhoria possa ser evidenciada em termos 
numéricos. 

□ Ter uma abordagem de gestão de mudança cultural: a implantação 
da Governança de TI tem impacto sobre o modus operandi do pessoal 
de TI, dos usuários e clientes da TI e dos fornecedores. As pessoas 
irão trabalhar de forma diferente e sempre haverá resistência, tanto 
passiva como ostensiva. Nesse contexto, deve-se planejar como será 
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feita a abordagem da mudança da cultura. Isso certamente exigirá 
uma série de novos comportamentos por parte do CIO e dos seus 
gerentes. 

□ Equipe qualificada: a implantação da Governança de TI exige uma 
equipe qualificada para tal. Portanto, deve-se procurar alocar pessoas 
que tenham os perfis requeridos para o planejamento, a implantação 
e o gerenciamento do programa. 

□ Certificar-se de que os benefícios previstos pela Governança de 
TI estão sendo atingidos: este elemento é crítico e talvez um dos 
mais importantes para um programa de Governança de TI. A alta 
administração somente entenderá os investimentos no programa se 
as melhorias puderem ser demonstradas através de números e, princi¬ 
palmente, da agregação de valor ao negócio. 




Estudos de Casos 


Os estudos de casos apresentados a seguir são fruto de nosso trabalho como 
consultores no mercado brasileiro em organizações de vários tipos de negó¬ 
cios, mais especificamente instituições bancárias, órgãos de governo e empre¬ 
sas de serviços. 

Para manter a confidencialidade, não identificamos as organizações. Simplifi¬ 
camos a apresentação dos casos, considerando o modelo de Governança de TI pro¬ 
posto neste livro, que contempla, para relembrar o leitor, os seguintes elementos: 

□ Papel e organização da Governança de TI. 

□ Riscos e compliance. 

□ Avaliação independente. 

□ Alinhamento estratégico. 

□ Entrega de valor. 

□ Gerenciamento de recursos. 

□ Gestão do desempenho. 

□ Comunicação. 

A seguir, são apresentados os casos mais representativos. 

□ Instituição Bancária: 


Elemento da Governança de TI 

Descrição 

Papel e organização da Governança 
de TI 

Há uma área com responsabilidade específica de Governança de TI 
visando assegurar o alinhamento estratégico da TI com o negócio, 
assim como prover visibilidade à diretoria acerca desse alinhamento. 
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Elemento da Governança de TI 

Descrição 

Compliance e riscos 

Há um sistema de gestão de riscos e compliance, sendo que são 
realizados testes planejados dos controles internos aplicáveis à TI. Caso 
sejam encontradas não conformidades, a área deve elaborar um plano 
de ação, que é acompanhado. Há também programas de auditorias 
internas, conforme o risco que o controle representa para o banco. 

Avaliação independente 

Há auditorias periódicas nas áreas de TI, realizadas por empresas de 
auditoria de primeira linha. 

Gestão da mudança organizacional 

Não há um plano de gerenciamento da mudança para sustentar 
melhorias e melhores práticas nas áreas de TI. 

Alinhamento estratégico 

A área de TI realiza o seu planejamento com base em BSC, a partir da 
estratégia comunicada do negócio. 0 modelo de direitos decisórios está 
bem estabelecido. A priorização dos projetos das áreas de negócio é 
realizada através de critérios institucionais aprovados pela diretoria. 

É elaborado um portfólio de projetos (incluindo os projetos 
estratégicos) que são monitorados. A estratégia de TI é monitorada 
em termos do atendimento aos indicadores de desempenho e de 
progresso das metas e objetivos de TI. 

Entrega de valor 

0 relacionamento com os clientes é regido por um processo 
definido. Há um modelo bem estabelecido para o gerenciamento 
de fornecedores. 0 desenvolvimento de projetos e o fornecimento 
de serviços de TI têm processos bem definidos e, na maioria, 
documentados. A organização estabelece acordos de níveis de 
serviços para atendimento às áreas de negócio, assim como para 
os seus fornecedores. Metodologias de gerenciamento da demanda, 
estimativas e projetos também estão definidos e documentados. A 
organização de infraestrutura possui certificação ISO/IEC 20000. A 
organização possui um conjunto de ações focadas na sustentabilidade 
das operações de serviços de TI. 

Gerenciamento de recursos 

0 orçamento de TI é gerenciado e acompanhado quanto à sua 
realização, inclusive gerando indicadores específicos. A organização 
investe significativamente em capacitação de seus recursos 
humanos. Estimativas de horas para o desenvolvimento são 
realizadas anualmente, visando determinar a necessidade futura de 
recursos. 

Gestão do desempenho 

Há indicadores operacionais sobre o gerenciamento de 
serviços, tais como disponibilidade de serviços, reutilização da 
infraestrutura, eficiência de suporte, taxa de entrega de projetos 
no prazo etc. Existem planos para a implantação de um dashboard 
para a gestão da TI abrangendo vários indicadores, dentro de uma 
perspectiva de BSC. 

Comunicação 

Há comunicação do desempenho de alguns indicadores e informações 
chaves das áreas de TI para conhecimento da diretoria e para 
subsidiar seu processo de tomada de decisão. 0 dashboard de gestão 
da TI começa a ser implantado de forma evolutiva. 
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□ Empresa de serviços: 


Elemento da Governança de TI 

Descrição 

Papel e organização da Governança 
de TI 

Há uma área específica para a Governança de TI, cuja ênfase 
é garantir a implantação e evolução de processos baseados em 
melhores práticas. 

Compliance e riscos 

Há um sistema de auditoria interna da empresa, visando garantir que 
os controles internos de TI sejam consistentes. 

Avaliação independente 

Há auditorias periódicas nas áreas de TI, realizadas por equipe de 
auditores externos. 

Gestão da mudança organizacional 

Não houve um plano para o gerenciamento da mudança no 
momento da implantação da Governança de TI. 

Alinhamento estratégico 

A área de TI realiza o seu planejamento com base em BSC, a 
partir da estratégia documentada do negócio. 0 modelo de direitos 
decisórios segue a estrutura de comitês já estabelecidos em nível 
de diretoria. Há um PMO corporativo que age na priorização dos 
projetos de negócio e gerencia o portfólio de projetos. 

Entrega de valor 

0 relacionamento com os clientes é regido por um processo definido. 
Há um processo maduro para o gerenciamento de fornecedores. 

0 desenvolvimento de projetos e o fornecimento de serviços de TI 
têm processos relativamente definidos. A organização estabelece 
acordos de níveis de serviços para os fornecedores. Metodologias 
de gerenciamento da demanda, estimativas e projetos também estão 
definidos e documentados. 

Gerenciamento de recursos 

0 orçamento de TI é gerenciado e acompanhado quanto à sua 
realização. 

Gestão do desempenho 

Há indicadores operacionais sobre o gerenciamento de serviços 
de TI como disponibilidade de serviços e capacidade e outros 
indicadores sobre a rede para fins de monitoramento. Existem 
algumas metas estabelecidas para TI e relativas a planejamento, 
compliance e maturidade dos processos de TI com base no CobiT. 

Comunicação 

Há comunicação para a diretoria sobre o desempenho das metas de 
TI, mas não há um dashboard de gestão de TI. 


□ Instituição de Governo Estadual: 


Elemento da Governança de TI 

Descrição 

Papel e organização da Governança 
de TI 

Há uma diretoria específica para Governança de TI, mas que 
também executa atividades de apoio ao CIO, tais como elaboração 
do planejamento e orçamento da área de TI. 
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Elemento da Governança de TI 

Descrição 

Compliance e riscos 

Os contratos de serviços são auditados pelo Tribunal de Contas do 
Estado. Há auditorias internas periódicas para verificar conformidade. 
Entretanto, não há um sistema de gerenciamento de riscos e de 
controles internos estabelecido. 

Avaliação independente 

Não há auditorias externas periódicas. Somente quando há 
ocorrência de graves incidentes. 

Gestão da mudança organizacional 

Não houve um plano para o gerenciamento da mudança no momento 
da implantação da Governança de TI. 

Alinhamento estratégico 

A área de TI realiza o seu planejamento com base em BSC, a 
partir da estratégia documentada da organização. 0 modelo de 
direitos decisórios segue a estrutura de Comitês já estabelecidos 
na organização. 0 planejamento de TI deve seguir um acordo de 
resultados com a Secretaria de Planejamento do Estado. 

Entrega de valor 

0 relacionamento com os clientes é regido por um processo 
definido. Há um processo maduro para a contratação de serviços 
de terceiros, com base na legislação vigente de contratação no 
serviço público. 0 desenvolvimento de projetos e o fornecimento 
de serviços de TI têm processos relativamente definidos com base 
em ferramentas. A organização estabelece acordos de níveis de 
serviços para os fornecedores. 

Gerenciamento de recursos 

0 orçamento de TI é gerenciado e acompanhado quanto à sua 
realização. 

Gestão do desempenho 

Há poucos indicadores, e a maioria são indicadores operacionais 
para o monitoramento dos serviços de TI, tais como central de 
serviços e gerenciamento de disponibilidade e capacidade. 0 acordo 
de resultado é monitorado. 

Comunicação 

Há comunicação para a diretoria sobre o desempenho das metas de 
TI, mas atreladas ao acordo de resultados. Não há um dashboard 
para a gestão da TI. 


□ Instituição de Governo Federal da Administração Direta: 


Elemento da Governança de TI 

Descrição 

Papel e organização da Governança 
de TI 

Há uma assessoria ao Diretor de Tecnologia que tem papéis de 
Governança de TI, além de outras responsabilidades. 0 foco da 
Governança de TI é garantir a conformidade com a legislação e 
diretrizes estratégicas de TI definidas pelo Governo Federal. 
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Elemento da Governança de TI 

Descrição 

Compliance e riscos 

Os contratos de serviços são auditados pelo Tribunal de Contas da 
União. Entretanto, não há um sistema de gerenciamento de riscos e 
de controles internos estabelecido. A organização de TI deve estar 
conforme Instruções Normativas do Ministério de Planejamento, 
Orçamento e Gestão (MPOG) e de acórdãos do TCU. 

Avaliação independente 

Não há auditorias externas periódicas, mas somente quando há 
ocorrência de graves incidentes. 

Gestão da mudança organizacional 

Não houve um plano para o gerenciamento da mudança quando da 
implantação da Governança de TI. 0 modelo de Governança de TI que 
é seguido pela organização foi estabelecido centralmente pelo MPOG. 

Alinhamento estratégico 

A área de TI realiza o seu planejamento com base em BSC, a 
partir da estratégia documentada da organização. 0 modelo de 
direitos decisórios segue a estrutura de Comitês já estabelecidos 
na organização. 0 planejamento de TI é revidado anualmente e 
elaborado a cada três anos. Há uma área para o gerenciamento 
de toda a demanda de projetos e que faz estudos de demanda e 
capacidade de atendimento. 

Entrega de valor 

0 relacionamento com os usuários é regido por um processo 
definido. Há um processo maduro para a contratação de serviços 
de terceiros, com base na legislação vigente de contratação no 
serviço público. 0 desenvolvimento de projetos e o fornecimento de 
serviços de TI têm processos relativamente definidos. A organização 
estabelece acordos de níveis de serviços para os fornecedores. 
Algumas melhores práticas estão implantadas. 

Gerenciamento de recursos 

0 orçamento de TI é gerenciado e acompanhado quanto a sua 
realização. 

Gestão do desempenho 

Há poucos indicadores, e a maioria são indicadores operacionais 
para o monitoramento dos serviços de TI, como central de serviços, 
disponibilidade e capacidade. 

Comunicação 

A comunicação sobre o desempenho de TI é esporádica e feita 
quando requerida. 


Como pode ser observado, ainda há alguns campos bastante profícuos 
para o aperfeiçoamento da Governança de TI nos mais diversos tipos de 
organizações. 

É mister observar que os bancos, pela própria natureza do negócio e em 
função da supervisão do Banco Central, apresentam uma Governança Corpo¬ 
rativa mais consistente que outros tipos de organização, refletindo, assim, em 
uma maior maturidade da Governança de TI. 
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